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.
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,
Jack Aaronson, CEO of The Aaronson Group and corporate lecturer, is a sought-after expert on enhanced user experiences, customer conversion, retention, and loyalty. If only a small percentage of people who arrive at your home page transact with your company (and even fewer return to transact again), Jack and his company can help. He also publishes a newsletter about multichannel marketing, personalization, user experience, and other related issues. He has keynoted most major marketing conferences around the world and regularly speaks at Shop.org and other major industry shows. You can learn more about Jack through his LinkedIn profile.
June 5, 2013
1:00pm ET / 10:00am PT