Business Rules for All

If you ask about documenting your business rules in a meeting, most people will think about business rules engines (BREs), otherwise known as inferencing engines. If your company isn’t using (or doesn’t plan on implementing) a BRE, the conversation probably won’t go far. Even without a BRE, however, the business rules methodology provides a way to document your company’s business rules and is important for all companies, not just those with an actual business rules engine.

What Is a BRE?

This column is more about the rule-discovery process, not the value of an actual BRE. First, though, a brief explanation of BREs. A BRE allows the rules of your business to be documented and stored separately from the code that runs your Web site or other software.

For example, there might be a business rule concerning how users purchase products from your company that states: “American customers must have a credit card number on file.” Another rule might state “European customers must have either a credit card or bank account number on file.” When a user signs up online for your services, these rules are imposed. If a customer identifies himself as living in America, the system will flag an error if the user doesn’t input a credit card number. If the user identifies himself as living in a European country, the system will flag him if he doesn’t entered a credit card or bank account number.

With a BRE, the rules are written in an English-like language by the company’s business side. Your Web site hooks into the BRE and uses the rules to enable error checking during the sign-up process. Without a BRE, error checking for a form is hard-coded in the pages that accept the form. Usually, this consists of on-page JavaScript or active server page (ASP) code. Whichever way the rules are implemented, they exist and were created somewhere in the company by a business person. Companies using a BRE could make changes to these rules easily, because the interface for rules creation (like the one in Outlook for forwarding mail that’s been received) is easy to use by a business person. If the rules (or constraints, in this case) are hard-coded by a programmer, changes aren’t as easy to make.

Document Your Rules

However these rules manifest themselves on the site, they exist. Someone at the company decided Americans need a credit card, and Europeans need a credit card or a bank account for fund transfers. Who decided this, and where are these business rules captured in the company? This is an important question because once the rules are hard-coded on a page, they can be difficult to extract later.

What if the programmer who coded them leaves? When new management takes over and asks what all the business rules surrounding the application process are, the new programmers will have to examine the code and try to figure out how every error message is triggered. This is obviously a suboptimal way to store and maintain your company’s business rules over time. In a rules-based engine, storage and maintenance are easier because they’re automated by the engine’s tools.

Separate Rule-Gathering From Rule-Use

Each BRE vendor has its own methodology for harvesting a company’s business rules. Many books and sites are dedicated to the art and science of business-rule creation and use. Most companies wouldn’t navigate business-rule harvesting if they weren’t also implementing a BRE. This is a mistake, though, because it leads to ad-hoc business-rule creation. Business rules are typically defined within each project and feature, but there’s no central place where all the rules exist. Decentralized business rules lead to confusion, and rules become difficult to maintain.

What happens, for instance, when a new business practice has slightly different rules than an existing one? What happens when multiple processes use the same rule, which now has to be changed? In a manual, hard-coded world, someone has to know every part of the system that touches that rule. In a BRE environment, that isn’t a concern.

For example, what if the company using the earlier credit rule decides to implement PayPal globally? The sign-up process now includes “credit card or PayPal” for Americans and “credit card or PayPal or bank account” for Europeans. This could be a straightforward change in the code, unless the logic is used multiple places on the site. Perhaps in addition to the sign-up process, the same restrictions apply to users applying for the company’s private-label credit card. In this case, the logic is probably duplicated on the pages of the second process. One business rule change now means multiple code changes, and those changes are prone to human error. What if you can’t remember all the processes that use those rules? The change might be made in the first instance, but not in the second.

Again, while these issues are solved by using a BRE, that isn’t my point. My point is that by documenting all business rules in a central place, documenting their origin, and documenting when and how they’re used, you create a traceable system for your business rules. Regardless of how they’re implemented, when a business rule changes there’s a formalized process for understanding the rule, what it impacts, and how it will be used. In the example, the addition of PayPal changes two fundamental rules in the enterprise (one about American customers and one about European customers). In a fully documented world, it would be easy to look up these original rules and see each business process that uses them. The project lead could then notify each owner of the various affected processes to ensure they adjust their systems to accommodate the revised business rule.

Not every company can afford a true BRE, and indeed one might be overkill for your company’s needs. What isn’t overkill, however, is the need for companies to have a defined process for business-rule harvesting and maintenance, regardless of how those rules eventually get enacted.

Questions, thoughts, comments? Let me know.

Until next time,


Related reading