April 15, 2012

Three Simple Rules for Titanic Fans

In 1492 Columbus sailed the ocean blue.  Every little child knows that three ships set sail to discover the New World. But did you know that only two ships survived the return trip?

The Santa Maria ran aground off the coast of Haiti on Dec. 25, 1492 and was destroyed. Columbus learned his lesson and the Sailing Rulebook was born.

420 years later Titanic sailed into an iceberg and the rulebook grew. 

100 years later Costa Concordia and Captain Schettino forgot Rules 1 and 2.

Titanic Rulebook




geovisit();<img src="" alt="setstats" border="0" width="1" height="1">

Continue reading "Three Simple Rules for Titanic Fans" »

October 19, 2010

10 Rules for Rules

Here are 10 rules for designing good business rules. They all happen to begin with the letter C. This was written somewhere over the Grand Canyon on the way to San Jose, CA for the 3rd annual RulesFest conference, where this was presented for the first time.

Click here to see the slides and hear a recording of the 7 minute presentation.

10 Rules for Rules

• Clear... not confusing
• Complete
• Correct
• Current
• Compliant
• Condensed
• Credible... not incredible
• Careful... not careless
• Common sense
• Consistent... not inconsistent


• Short link to that page:
• Please use Twitter hashtag #BIZRULES
• Follow us on Twitter username @BizRulesInc
• Comments for this article: TBD
• See also:

September 17, 2009

Business rules drag Orbitz down to Earth

Orbitz just lost its cool.

I just booked a roundtrip flight from Dallas to Atlanta. The outbound flight is at 5:30AM CDT. The return flight is at 4:05PM EDT. Each flight is about two and a half hours long.

But according the Orbitz' email confirmation:

  1. This is an overnight flight.
  2. This flight arrives two days later.
  3. This flight arrives on the previous day.
  4. This flight arrives two days prior.
  5. This flight departs from a different airport.
  6. This trip starts and ends at different airports.  (see the rest of the email text below)

WOW! There is just way too much information here to absorb. I need to take this one step at a time so it can really soak in.

First, "this is an overnight flight." Do you know if you have to pay for pillows and blankets nowadays?

Second, "this flight arrives two days later." Apollo 11 took four days to get to the moon. (July 16-19, 1969)

Third, "this flight arrives on the previous day." Now that I can believe! Believe it or not, that would be the second time this ever happened to me. Once I flew out of Tokyo at night on my birthday. I arrived in Hawaii in the morning, on my birthday. The International Date Line is cool that way. (see

Fourth, "this flight arrives two days prior." Back to the Future. Sounds like a good time to buy some stocks before takeoff.

Next, "this flight departs from a different airport." I hope they have a fast shuttle bus.

Finally, this trip starts and ends at different airports. I guess that message is OK. The main reason I booked this trip is to get from one city to another. So this message is technically correct. I've never seen this message before in Orbitz email confirmations, so this could be a new system enhancement to improve customer service: it's good to let customers know that they will land in a different place than where they took off from. That's all good. So that's not really a bug. It's more like a feature.

This automated email has 5 or 6 mistakes, depending on whether you think #6 is a bug or a feature. Actually 10 or 12 mistakes, because the messages were listed for each flight. That's not good.

Orbitz has a business rule problem. Somewhere in the system, rules are missing or they are just plane wrong. Orbitz needs to improve their business rules management system. Orbitz needs to figure out what their business rules are and what they should be. They need rules that are correct, complete, compliant, consistent, clear, and concise.

That's what Orbitz needs. And what Orbitz customers deserve.

Rolando Hernandez, CEO,

NOTE: Below is an excerpt of the Orbitz email

Your Travel Document


Thanks for traveling with Orbitz. This e-mail confirms the ticket number(s) issued for the "Atlanta <DepartureDate>" trip.

Delta Air Lines # 1912
Dallas/Fort Worth International (DFW) to Atlanta Hartsfield-Jackson ATL (ATL)
Departure (DFW): <DepartureDate>, 5:30 AM CDT (morning)
Arrival (ATL): <DepartureDate>, 8:48 AM EDT (morning)

 This is an overnight flight.

 This flight arrives two days later.

 This flight arrives on the previous day.

 This flight arrives two days prior.

 This flight departs from a different airport.

 This trip starts and ends at different airports.

Delta Air Lines # 67
Atlanta Hartsfield-Jackson ATL (ATL) to Dallas/Fort Worth International (DFW)
Departure (ATL): <ReturnDate>, 4:05 PM EDT (afternoon)
Arrival (DFW): <ReturnDate>, 5:34 PM CDT (evening)

 This is an overnight flight.

 This flight arrives two days later.

 This flight arrives on the previous day.

 This flight arrives two days prior.

 This flight departs from a different airport.

 This trip starts and ends at different airports.

Update 1: An Orbitz customer service rep said this was due to Delta merging with Northwest. The inventory data from Delta is messed up she said. I wonder how many people received these warnings and error messages.

Update 2: A good place to go for more information on business rules management and rulebase techology is


February 04, 2009

WARNING: CEO's need to wise up and "bail out" of billion dollar IT projects right now

WARNING: CEO's need to wise up and "bail out" of billion dollar IT projects right now

Dear CEO: 

I am sick and tired of reading about billion dollar IT projects that we both know are never going to work, change, or last. It's time to stop the non-sense and use common-sense.

Here's just one example from InformationWeek. California is spending $3,600,000,000 (that's $3.6 BILLION) on these systems:

• Financial system: 11.8 years, $1.6B
• Strategic Offender System: 5.7 years, $416M
• Home Support Services: 10 years, $298M
• Automated Welfare System: 3.8 years, $263M
• Child Welfare System: 7.3 years, $254M
• Motor Vehicles IT Modernization: 6.8 years, $207M
• Consolidate IT Infrastructure: 2.9 years, $191M
• HR System: 6.1 years, $179M
• ERP for Prisons: 4.5 years, $176M 

Do you really want to cut your systems development budget?

Here's how:

Let's say you're planning an 18-month $18 million systems development project. Imagine that's the cost and time for analysis, design, programming, testing, and deployment.

Using business rules, rulebases, rulebased technology, and architecture and engineering principles, we can program that system in 12 months and $12 million. It's that easy.

We can save you 6 months and $6 million just by using rule-based programming languages instead of hard-coding your rules.

If you can tell us exactly what all your business requirements are, and how many business rules you have, well then we can bring your costs down even more.

We can find enough good qualifed experienced out of work programmers right now who are just as cost-effective and as productive as any programmer in any country who would love to work on your project. And they're ready to start as soon as you're ready to save $$$.

When do you want to start saving millions of dollars?

Hurry, you must act now. Call 1-800-SAVE. The first 50 callers will save an additonal $1 million if you call in the next 30 days. You must call before shareholders find out how much you're really spending on systems development.

PS - By the way, for every $1 billion you spend on development, you're spending $5 billion on maintenance. It's time to stop IT non-sense. You must call now!

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

Principles are Coming

Principles are Coming

More judgment and knowledge needed

While the finance industry is moving toward more rules and exceptions, and rules-based regulation, financial accounting and reporting is moving in the opposite direction, towards fewer rules and exceptions. Accounting and tax is moving towards more principles-based regulation.

The US is moving away from GAAP (Generally Accepted Accounting Principles) and towards IFRS (International Financial Reporting Standards). IFRS is the reporting framework used by most of the world today, and it has growing support in the US. IFRS relies on professional judgment rather than detailed rules. Under this principle-based approach, management will have a mandate and obligation to exercise its own best judgment when making decisions.

Companies will need to implement systems that use knowledge and judgment to make principle-based decisions.

It is time to adopt knowledgebase technology and knowledge management. It's time to build knowledge bases and embed knowledgebased technology into operations and existing systems.

Knowledgebased systems that are engineered and architected properly can

  • follow principles and guidelines
  • automate management's best judgment
  • ensure compliance
  • and deliver trust. These expert systems can be trusted because they use expert judgment to make the same decisions top experts would make, thus improving the quality, accuracy, and consistency of decision-making.

I don't believe there is any other practical or proven way of automating human judgment, other than building intelligent, knowledge-based systems.

Knowledgebased systems are the solution for principle-based compliance.

Rules are Coming

Rules are Coming 

More rules and regulations are coming

To restore trust in the financial system, the government is moving towards more rules and exceptions, and more rules-based regulation. The trend towards de-regulation is over. Regulatory reform is coming back. That means more rules and regulations than ever before.
Management will have an obligation to follow the rules and laws when making decisions. These decisions better be consistent, correct, complete, and compliant if you really want to stay in business. 

Companies will need to implement systems that follow the rules and make rule-based decisions.

It's time to adopt the business rules approach and business rules management. It's time to build rulebases and embed rulebase technology into operations and existing systems.

Rulebased systems that are engineered and architected properly:

  • follow the rules
  • automate management's decisions
  • ensure compliance
  • and deliver trust. Rule engines can be trusted because they implement the decisions management intended.

Rulebased systems and business rules management are the solution for rule-based-compliance.

March 13, 2008

Introducing the BIZRULES® RuleMap™

Documenting business rules is a good first step on the path towards the business rules approach.

But sometimes that's not enough.  Taking the next step and getting to the next level requires simulating business rules so they are easy to review and verify.

Over the past few months BIZRULES has been working on a new product that lets us do both. It's a visual tool that lets us not only draw diagrams of business rule models, it also lets us simulate the rule logic. This tool helps us speed up the rules harvesting process and improves the quality of our rulebooks.

BIZRULES® RuleMap™ is an interactive rulebook that models business rules and simulates business logic.  This logical model lets you see how your business rules really work. It lets you visualize the Reasoning Chain™ that leads to smart conclusions and right decisions.

We use this tool to document your business rules independent of any BRE - yet it can be implemented using any BRE. Again, this is a logical model of your business rules.  It can be used as the rulebook or specs for authoring the rules in any BRE.

Take a look at a sample RuleMap. And let us know what you think. Contact us for pricing or a web demo.



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."


March 16, 2007

Best Buy, Bogus Prices: Confusion about pricing rules reveals need for business rules management

If employees don’t know, don’t understand, or don’t care what the rules are, you have a business rules problem.

If customers get different answers depending on who they talk to, you have a business rules problem.

If salespeople can decide whether to charge the right price or a bogus price, you have a business rules problem.

Best Buy, the nation's largest electronics retailer, has a business rules problem.

It's also dealing with a public relations nightmare, and an investigation by the Connecticut Attorney General's Office.

Pricing rules used by salespeople in Best Buy stores are inconsistent and contrary to Best Buy pricing policies established in the boardroom. “What we've learned very quickly is we have not been clear enough in communicating to our employees the policy, and how to execute it in our stores,” said Dawn Bryant, spokeswoman for Best Buy.

Success in the world of business depends on understanding the rules,” I said recently during a panel discussion on Sarbanes-Oxley compliance.

“You need to know the internal rules and policies of your business. You have to comply with the external rules and regulations that govern your business, industry, and function. Your company must ensure that rules are followed. Your company must enforce the rules. Your company must give staff tools to help them follow the rules, make legal decisions, and prevent them from making illegal decisions. Business rule management systems (BRMS) and business rule engines (BRE) help companies comply with rules and regulations like SOX.

If you don’t have a rule engine that automatically prevents employees from breaking the rules and instantly detects and prevents fraud, you’re out of the game. You’ll end up watching your stock go from $30 to $3 during lunch. You lose. You’re out of business.

Smart companies are using business rules to ensure compliance with rules, to enforce rules, to increase agility so they can change faster, to prevent business mistakes, and to reduce IT system development costs by changing rules in days not months.

Business rules technology helps business comply with rules and regulations, helps employees follow the rules, and prevents employees from breaking the rules (either accidentally or on purpose).”

Business rules management is the prescription for business rules problems. Business rules management entails everything from the business rules approach to business rules technology. 

The business rules approach helps companies transform complex policies into easy to understand business rules. What better way is there to clearly describe and communicate policies and business rules to employees?

Business rules technology helps companies execute the right business rules at the right time every time. What better technology is there to automate business rules?

What happened at Best Buy is a great example of what can go wrong when business rules are not designed and engineered properly.

Business rules are like the glue that holds together all the parts of the corporation. Business rules integrate and align all the moving parts of the corporation. With business rules management, Best Buy can ensure that rules and processes used in the stores are aligned with Best Buy pricing policies defined in the boardroom.

Without business rules management to connect the elements of the corporation, the only way to ensure the corporation works as intended is to "hope and pray," as John Zachman likes to say. With weak or wrong business rules, the corporation falls down like a house of cards.

This is why business rules management is vital to the corporation.

Business rules management is not just about documenting business rules, defining who the owners are, and deciding who is authorized to change them. It’s not just about using rule-based languages to speed up system development instead of hard-wiring rules in legacy code. It’s not just about selecting a business rules engine. It’s not just about understanding the company’s strategies, policies and business practices, and then transforming those objectives into rulebooks, descriptive business rule models, IT specifications, and finally into automated systems.

Business rules management is also concerned with architecting and engineering the business rules so they are integrated with the rest of the business. This helps ensure that the implemented business rules that are in actual use, whether automated or manual, align with the governing rules and strategies of the business.

What happened at Best Buy?

At first, I thought the Best Buy pricing problem was complicated and hard to explain. Then I wondered how can business rules help solve this problem? What would BIZRULES do if Best Buy came to us for help?

That’s easy. I like to draw pictures to simplify complex ideas. By removing the complexity, pictures help me make even the most complex concepts easy to understand:

BIZRULES Analysis of Best Buy Pricing Rules 

(Click to see medium or large slide)

This is an example of three business rules that were apparently in operation at Best Buy when this story broke. Of course, we really don't know the rules were, so this is just a good guess based on published news accounts of what really happened.

Along with a picture of the rules, this slide shows how the rules affect the rest of the company. It also shows how the rules satisfy business rules management objectives, and business rule engineering design objectives:

Rule #1 is a conceptual explanation of the pricing policy to honor the lowest price.

  • This rule tells us what management means and what their intentions are.

Rule #2 is a logical description of the corporate policy to honor the lowest price:

  • This business rule clearly shows alignment to corporate strategy.

  • This is the high quality rule prescribed by the pricing strategy.

  • This rule shows integration between online and retail stores.

  • This rule offers reusability – the same rule can be implemented online and in the store.

  • This rule shows transparency.

  • This rule reduces operations costs because it’s easy to follow.

  • This rule demonstrates regulatory compliance.

  • This picture is worth a thousand words.

  • This rule builds Customer Trust Management.

  • This is a “Best Buy” type of rule.

  • This rule is easy to approve, assess, test, and certify.

  • This rule improves governance and controllership.

Rule #3 is used (i.e. prescribed) by some salesman to mislead customers into paying higher prices:

  • This business rule is clearly not aligned to corporate strategy.

  • This poor quality rule is operational and being used in stores.

  • This rule shows discontinuity and inconsistency between online and retail stores.

  • This store rule cannot be reused online because it lacks transparency.

  • This rule increases operations costs because it’s hard to explain and justify.

  • This rule raises questions about regulatory compliance.

  • You need a thousand words to explain this picture.

  • This rule destroys customer confidence and trust.

  • This rule is public relations nightmare.

  • This rule may be illegal.

  • This is a “bait & switch” type of rule.

  • This rule should never have been approved.

  • This rule raises questions about whether proper rules, processes, and controls are in place.

Now that I understand what the current pricing situation at Best Buy is, it seems pretty straightforward:

  • Management intention is Rule #1. This is Best Buy’s pricing policy.
  • Marketing description is Rule #2. This is what marketing thinks is happening.
  • Sales prescription is Rule #3. This is what salespeople are actually doing.
  • IT specification is not applicable in this example because these rules have not been automated. If these rules were automated, an executable specification of the rule (i.e. pseudo code) may need to be developed for the programmer.

These four views of the business rules fit nicely into an Enterprise Rules Architecture.

The next step is to fit these rules into an enterprise architecture framework. I used John Zachman’s influential and compelling Framework for Enterprise Architecture as an example:

The Zachman Framework for Enterprise Architecture

(Click to see medium or large slide)

Next, I overlaid Best Buy Rules #1-3 on top of Zachman’s Enterprise Architecture Framework to add more clarity to the Best Buy pricing situation:

BIZRULES Analysis of Best Buy Pricing Rules (part 2)

 (Click to see medium or large slide)

The pricing problem at Best Buy is that the business rule used by salespeople in the stores contradicts the company’s pricing policy. Clearly Rule #3 is not aligned with Rule #1 or Rule #2.
Business rules confusion is what caused the problem.

Business rules management is the solution.

To get out of this sticky mess, Best Buy needs to:
  • establish or improve their business rules management.
  • prevent salespeople from using Rule #3 immediately
  • mandate use of Rule #2 immediately.
  • automate Rule #2 as soon as possible. Why let salespeople decide pricing at all? Let the computer figure out what the lowest price is.
  • use a business rule engine to automate this rule as quickly as possible. This rule change needs to happen overnight. But changing hard-wired rules in code takes take days or weeks. Often, companies that don’t use rule engines take months to change business rules as simple as these. This is one reason why companies buy rule engines: Changing rules in a rule engine takes minutes.
  • educate salespeople on the pricing rules. Of course, if Best Buy automated the rules using a rule engine, they wouldn’t need to train as much.
  • ensure compliance with these rules from now on.
What about the secret website?

Business rules can also help Best Buy get rid of the secret and duplicate website. It's hard enough to maintain and manage prices for thousands of products on one website, let alone two. There are costs associated with maintaining a duplicate site containing 250,000 pages; surely management and shareholders want to reduce redundant costs like these. One way is to use a business rule engine to eliminate the duplicate site and duplicate effort. Why not write a few rules to show different prices (if that really is management’s objective) depending on whether the salesman pulls up the web pages on the Internet or the "secret website" on the Intranet?

How else can business rules management and business rules technology help Best Buy? Please comment and let me know.

Rolando Hernandez

CEO & Chief Rules Architect, BIZRULES


1 1 1


Continue reading "Best Buy, Bogus Prices: Confusion about pricing rules reveals need for business rules management" »

March 14, 2007

Enterprise Rules Architecture

In case you are new to business rules, I’d like to go over a few basic terms and facts about business rules and enterprise architecture. Understanding terms and facts is one of the first steps in the business rules approach.

The purpose of the corporation is to perform a business function. The function of most corporations is to make a profit for shareholders by selling products and or services. Corporations comply with external rules, laws, and regulations that specify what the corporation can, should, must, and must not do. They calculate and pay tax, and they report information and file submissions with government agencies.

Corporations establish missions, goals, and strategies such as “sell more and increase profit.” They define internal business rules, policies, procedures, processes, and flows to support the strategies while assuring regulatory and statutory compliance. They put in place business rules to guide macro and micro decision-making and help management plan, manage and improve the operation.

Corporations open stores and branch offices in places and jurisdictions that they would like to do business in, and where customers can go to shop, buy, and transact. They hire employees and educate them on the goals and processes, and train them on the rules.

Corporations design, build, use, and manage information systems, business systems, and database systems for managing, transacting, reporting, decisioning, advising, and automating business functions. These systems have a business purpose, function, structure, behavior, and logic.

All these elements that make up the corporation can be represented by an enterprise architecture framework.

One influential and compelling concept of enterprise architecture was defined in the 1970s by John Zachman when he described his Framework for Enterprise Architecture. The Zachman Framework (click to see it small, medium, or large) consists of descriptive models that describe all the elements of the corporation and the business models of the corporation.

The elements of the corporation include shareholders, employees, and customers (who); data, information, and systems (what); events, plans, schedules, and flows (when); locations, stores, offices, domain names, and networks (where); processes, programs, and code (how); and goals, strategies, policies, and business rules (why).

The business models (i.e. views or perspectives) of the corporation are contextual scope (planner view); conceptual business model (owner); logical system model (designer); technology model (builder); and detailed specifications (sub-contractor).

Business rules integrate and align all the elements and business models of the corporation. Enterprise rules architecture ensures that the functional and structural components of the business rules required for the corporation to fulfill its business function will work, change, and last.

Business rules management entails the business rules approach, business rule methodologies, best practices, rule harvesting, rule modeling, business rule engineering design objectives, enterprise architecture, enterprise rules architecture, rulebase architecture, terms glossaries, semantic modeling, business rule engines (BRE) and business rules management systems (BRMS).


New Power for Management: Business Rules

Understanding and managing business rules is vital to the corporation. It is just as important as managing people, processes, and information.

Nevertheless, business rules are often misunderstood and poorly managed.

Many rules remain unwritten – they are known only to and retained by subject matter experts who sooner or later leave the corporation, causing brain drain. When business rules are written, they are seldom shared and reused throughout the corporation, which increases operating costs. When business rules are automated, they may not be aligned to the business strategies and policies, leading to quality problems.

In order to program business rules, programmers often rely on unclear business rule specifications that are incomplete or incorrect. Then they usually hard-wire the business rules in computer languages that only programmers can understand and change.

Because programmers are not directly involved in the day-to-day operation of the business, they often make assumptions about what the rules are and what management intended. That leads to mistakes or bugs in the programs, which requires further programming and re-programming.

There is a solution.

Some corporations use advanced business rules technology and business rule management methods to take business rules out of IT and bring them back into the business. Now management can finally manage and change their business rules.

Business rules management techniques help management clearly describe and communicate business rules to employees, partners, and customers. Business rule management software helps automate the rules that should be rule-based.

Business rules improve the condition of the corporation. They prevent business mistakes and minimize risk. They solve many critical problems facing business and IT.

Business rules are like the glue that holds together all the parts of the corporation, ensuring that the automated rules align with goals and strategies.

Business rules integrate and align all the moving parts of the corporation into a cohesive enterprise architecture and operating system that works, changes, and lasts.

Business rules give new power to management.

1 1

Continue reading "New Power for Management: Business Rules" »

August 21, 2006

Business Rules Revolution - Executives across all industries are using technology to rewrite the rules of business — literally.

By Kristine Blenkhorn Rodriguez

Reprinted courtesy of INSIGHT Magazine, The Magazine of the Illinois CPA society. For the latest issue, visit

IT’S ONE OF THOSE TOPICS THAT MANY EXECUTIVES DON’T LIKE TO admit they don’t know quite enough about. So they nod sagely while their tech savvy counterparts discuss the business rules “revolution.” The revolution part is easy enough to understand. But what exactly are business rules, at least in this context?

Business rules are the rules by which you run your business. Sounds too simple, right? Wrong. They can encompass any area, from tax withholding for employees to marketing strategy when a major competitor turns up the heat. Many are unspoken. They reside in the legacy code held within your computer systems. And they reside within your executives’ heads. Therein lies the problem, and here cometh the “revolution.”

“We’ve been implementing business rules ever since computers became mainstream,” says Ron Ross, a member of the Business Rules Group, an organization of professionals from the public and private sector who are dedicated to developing and supporting business rules standards, among other things. “We’ve taken a rule and translated it into computer code so your systems do what they need to do when they need to do it to help you run your business.”

Not necessarily revolutionary. But, with the increasing popularity of business rules engines— software that can be bought as a stand-alone item or as part of an enterprise system—your business rules have become simpler to create and change. “You use rules engines to change the behavior of your programs without having to reprogram anything,” explains Paul Haley, founder, EVP and CTO of Haley Systems, Inc, a technology solutions provider specializing in business rules management systems.

For example, he explains, take any sort of financial business. “Your staff goes by many rules. They probably say things like, ‘Revenue from a contract will not be recognized on balance sheets until the invoice is paid’ or ‘Here’s how we delineate between expense and capitalization.’ These rules are changes that occur on a regular basis as your business situation or pricing, etc. changes. You used to have to call in your IT people every time something like this was altered. They’d bring in an army of programmers who would then code everything to reflect the change. This could take some time and could get expensive on projects you had outsourced. A rules engine takes the specification of conditions, if X then Y, out of programmers’ hands and puts it into your executives’ hands.”

That change is key, says Rolando Hernandez, CEO and chief rules architect of BIZRULES, a firm specializing in business rules, business process and knowledge management. “You save time because you’re not hard-coding rules, anymore. Business rules engines are basically software development programs that minimize programming. They separate business logic from computer code, which allows business people—not programmers—to edit and change rules using a simple, user-friendly interface and plain English.”

The advantages, Hernandez explains, are plentiful. You reduce your time to market. You prevent business mistakes and fraud. You retain knowledge that might otherwise be lost through attrition. You manage risk by increasing the probability of across- the-board compliance. And you reduce application development and maintenance costs because you have enabled your own businesspeople—who make the rules—to write the rules instead of relying on a programmer to hard-code them.

Revolutionary? Yes. But not exactly new. Business rules in this form began in the 1980s, when rules engines were known as “expert system inference engines.” Which means that, while many companies haven’t yet taken advantage of business rules engines, they are far from their nascent stage, and are already a proven mission-critical technology in the Fortune 500.

But if you’re after revolutionary and new, then here you go: According to Hernandez, many call center operators here and overseas ultimately will be either aided by artificial intelligence (AI) business rules engines or replaced by knowledge-based expert systems that will give the right answer every time, 24/7.

“Imagine a call center with 200 people,” he explains. “There is high turnover in the center and a lot of your staff is new much of the time. These are your front-line employees, not senior execs, on the phone with your customers. The problem is that customers get different answers depending on who they talk to. Business rules can be applied here to improve service delivery. If operators were using rules engines, your customers would get the same, right answers every time. You could put this intelligence on the Web and enable customers to help themselves, using the knowledge and rules of your best experts. That could eventually eliminate some of those operators, but it will certainly reduce customer service costs. AI-based and rules-based self-service customer support websites will emerge and customers will love them. Expert answers; instant gratification.”

It all sounds well and good, but does it fly in the real world? Marty Colburn, CTO and EVP for the National Association of Securities Dealers (NASD) cannot speak with firsthand knowledge of AI-based systems, but he can attest to the success traditional rules engines have brought the companies he’s worked for.

“We have billing streams that enter our system through PeopleSoft,” Colburn explains. “We needed to change them, so we purchased a rules engine. It took us one month to develop the new rules and one month to implement them. It cost us $200 thousand. Without the rules engine, it would have been a seven-figure project that took a year to complete. There are clearly advantages of scale and economy when you use business rules engines. Your time to market is much faster, and your cost and schedule improve immensely.”

Colburn worked for Fannie Mae in the early 1990s, where he also used business rules technology. “We built an underwriting and origination system,” he recalls. “We were ahead of the times then because rules engines were still not in widespread use. But the results were similar to what NASD has experienced. A huge improvement.”

“The primary goal today is agility,” Ross explains. “Rules need to change as quickly as your business changes. Your business analysts want to be able to get their hands on rules without digging through mountains of code to do it. They need to evaluate the impact of rule changes quickly so you can quickly determine the route you want to take. It’s literally impossible to operate a business at scale, across the globe, without automation.”

Hernandez sees global clients reap immense benefits from rules engines. “One of our Fortune 10 clients is using rules engines for global statutory compliance, including SOX,” he explains. “How do you manage global tax compliance across multiple tax jurisdictions, multiple ERPs and multiple P&Ls? How do you manage risk across hundreds of legal entities and P&Ls over 200 countries, and a variety of products, services and IP? How do you manage a tax return consisting of over 20,000 pages across many countries in every region of the world? How else can you close the books on time, every time? A $3 million investment in business rules engines, rules harvesting and knowledge engineering has helped this client greatly increase its chances of across-the-board compliance. This change done via the traditional hard-coding programming route would have cost $30 million.”

Compliance with Sarbanes-Oxley regulations is a natural fit for business rules engines, according to our experts. “SOX maps very well to this solution,” says Hernandez. “If you go to all that time and expense to document, assess, test and certify your processes and controls (i.e. business rules) anyway, then it’s relatively easy to get to the next level of compliance by using a rule engine to simulate and automate them.”

With business rules automation, says Haley, “You gain precision and control. What you say is what runs in your systems. And you know what is running in your systems. Put simply, it gives your executives more power, speed, agility and precision. The IRS, Wells Fargo, GE, GM, Cigna and a host of other companies are doing this. I’ve seen analyst estimates that 80 percent of companies will be using business rules by the end of 2007. In 2005, I think it was something like 20 percent of companies. Business rules are here.”

Sarbanes-Oxley panel discussion at the iCoast Tech Show 2006

Below is an excerpt of my opening remarks during the panel discussion on Sarbanes-Oxley Regulation at the iCoast Technology Show in Ft. Lauderdale on August 17th.

Success in the world of business depends on understanding the rules.
You need to know the internal rules and policies of your business. You have to comply with the external rules and regulations that govern your business, industry, and function. Your company must ensure that rules are followed. Your company must enforce the rules. Your company must give staff tools to help them follow the rules, make legal decisions, and prevent them from making illegal decisions.

Business rule management systems (BRMS) and business rule engines (BRE) help companies comply with rules and regulations like SOX.

How many of your companies have implemented a business rules management system or business rules engine?

Well, it’s very difficult to comply with SOX, especially 404, without rules technology.

Somebody somewhere is always changing a rule and redefining what it means to comply, and your business must continually adjust.

There is nothing usual about business as usual… because rules are always changing. SOX rules will keep changing. Companies are going from regulated to heavily regulated. The change is constant. And the rate of change is increasing faster and faster. The problem is that software code is very difficult and time-consuming to change. If SOX business rules are hard-wired in code, it takes IT programmers weeks and months to change rules in code.

If business rules are stored in a rulebase, however, instead of hard-wired in code, it takes business people minutes and hours to change the rules in the rulebase, with minimal or no IT involvement

So what? What does that mean to you?

Well, here's your take-away - Here's what your CEO needs to know about rules and SOX compliance:

If your competitor uses rule engines, that means they can change their business rules on-the-fly without having to recode and recompile. They can change their rules instantly, with zero time-to-market, as the business changes, as the world changes, as customers change, as regulations change.

If they can keep up with change, they can stay in the game.

If your company doesn't use rule engines that means you have to go through IT to change your business rules. You have to get a programmer to change the code, test it, debug it, recompile it, test it, debug it, recompile it, etc. It's going to take you a while to change the rules. It might take a few weeks or more likely a few months to change the business rules in the systems, as the business changes, as the market changes, as customers change, as regulations change.

If you can't keep up with change, you're out of the game.

You lose - - They win.

If you don’t have a rule engine that automatically prevents employees from breaking the rules, SOX rules, and instantly detects and prevents fraud, you’re out of the game. You’ll end up watching your stock go from $30 to $3 during lunch. You lose. You’re out of business.

The solution is business rules management.

Smart companies all around the world are using business rules to ensure compliance with the rules, and to enforce the rules, to increase agility so they can change faster, to prevent business mistakes, and to reduce IT system development costs by changing rules in days not months.

One of our clients, a fortune 10 company, is implementing business rule management systems and business rule engines for global statutory compliance, including Sarbanes-Oxley. A $3 million investment in business rule engines, rules harvesting, and knowledge engineering has helped this company greatly increase its chances of across-the-board compliance. This change done via the traditional hard-coding programming approach would have cost $30 million.

So… business rules technology helps business comply with rules and regulations like SOX, helps employees follow the rules, prevents employees from breaking the rules (either accidentally or on purpose), helps government educate people and business about what rules are, and helps government enforce the rules.

If government is using rule engines to catch honest mistakes and detect outright fraud, then the smart business will use rule engines to prevent mistakes and prevent fraud in the first place.

Rolando Hernandez

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


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


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.

July 19, 2005

The Business Rules Manifesto

The Business Rules Group, an independent standards group of business and IT professionals, published The Business Rules Manifesto, principles of rule independence.

It looks like a "Declaration of Independence for Business Rules", and it is pretty interesting reading for people interested in the rules movement. The original document is here:

The Business Rules Manifesto*

Article 1. Primary Requirements, Not Secondary

1.1. Rules are a first-class citizen of the requirements world.

1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

2.2. Rules are not process and not procedure. They should not be contained in either of these.

2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.

3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.

3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.2. If something cannot be expressed, then it is not a rule.

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.

4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

4.7. Exceptions to rules are expressed by other rules.

Article 5. Well-Formed Expression, Not Ad Hoc

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation

6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.

6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

6.4. Rules are based on truth values. How a ruleís truth value is determined or maintained is hidden from users.

6.5. The relationship between events and rules is generally many-to-many.

Article 7. Rule-Guided Processes, Not Exception-Based Programming

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

Article 8. For the Sake of the Business, Not Technology

8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.

8.2. Rules always cost the business something.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

8.4. More rules is not better. Usually fewer good rules is better.

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 9. Of, By, and For Business People, Not IT People

9.1. Rules should arise from knowledgeable business people.

9.2. Business people should have tools available to help them formulate, validate, and manage rules.

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms

10.1. Business rules are a vital business asset.

10.2. In the long run, rules are more important to the business than hardware/software platforms.

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.

Copyright, 2004. Business Rules Group.

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged, or extended in any manner.

Note: The original document is here:

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