Principles of the Business Rule Approach: The 'Flow' and the 'Know'
This chapter is from the book
This chapter is from the book
This chapter is from the book
Databasing Your Rules
How many rules does your company have? A hundred? A thousand? Ten thousand? More? How easy is it to change any one of those rules? How easy is it to determine where the rule is implemented? How easy is it to find out why it was implemented in the first place?
Many companies today are starting to realize they have problems with rule management. Often, this perception did not start off that way. Initially, the perception might have fallen under some other label such as change management, data quality, knowledge retention, communication gap, or so on. Call it what you may, these companies are discovering that the business logic at the core of their day-to-day operations is not being managed in any consistent or coherent manner.
Databasing the Rules
The purpose of rule management is to provide the infrastructure necessary to correct that problem. Such a solution assumes, of course, that rules can be managed. But why not? In one sense, the literal specification of rules is just data, and in general, we certainly already know how to manage data.
So the first and most basic principle in rule management is that your rules should be databased. In other words, you should store the rules in an automated facility or repository where they can be managed and readily accessed.
Then comes the question of what else to store besides just the rules themselves and what additional kinds of support are needed. The key lies with remembering that business rules represent business logic—not programming logic. The goal of rule management is to give business workers and/or business analysts the ability to manage and access their business logic directly. The focus should be on the kinds of challenges these business workers and business analysts face on a day-in-and-day-out basis.
Fundamental in this regard is vocabulary management. When rules number in the thousands—or even just in the hundreds—coordinating business terminology becomes essential. Imagine trying to understand and apply that much business logic without such coordination. In practice, rule management is not simply about coordinating rules but also about coordinating the underlying business vocabulary. It is hard to stress this point too much.
In thinking about the other needs of business workers and analysts, it turns out that many of their questions about rules are quite predictable. Frequently asked questions include those listed in Table 13–1. Although the importance of these questions is self-evident, most companies have never managed this kind of core knowledge in any coordinated or comprehensive manner.
Table 13-1 Typical Questions Business Workers and Business Analysts Could Ask about Rules
| To which areas of the business does a rule apply? |
| What work tasks does a rule guide? |
| Where is a rule implemented? |
| In what jurisdictions is a rule enforced? |
| What purpose does a rule serve? |
| What deliverables in a new system design need to address a rule? |
| When was a rule created? |
| When did a rule become effective? |
| Are there previous versions of a rule? |
| Is a rule still in effect, and if not, when was it discontinued? |
| Was a rule retired or replaced, and if so, why? |
| What influenced the creation or modification of a rule? |
| Who can answer particular kinds of questions about a rule? |
| Who has been involved with a rule over time, and in what way? |
| Where can more information about a rule be found? |
Traceability
Another question crucial to managing rules is being able to address relationships between rules—that is, rule-to-rule connections. There are many ways in which rules can be interconnected, as the list presented in Table 13–2 suggests. Being able to trace these relationships easily and reliably is also crucial to rule management.
Table 13-2 Kinds of Rule-to-Rule Connections
| A rule is an exception to another rule. |
| A rule enables another rule. |
| A rule subsumes another rule. |
| A rule is semantically equivalent to another rule. |
| A rule is similar to another rule. |
| A rule is in conflict with another rule. |
| A rule supports another rule. |
| A rule is interpreted from another rule. |
The items in this list of connections, as well as the typical questions in the earlier list, illustrate various forms of traceability. Comprehensive support for rule traceability is a key ingredient in successful rule management.
How can such support be achieved? Databasing your rules is one part of the solution. Equally important is providing appropriate access to them once stored. Predefined reports and queries provide many kinds of basic support in that regard. Beyond that, visualization techniques are very useful for presenting more complex or highly interrelated information.
In one way or another, I believe that every company will eventually discover the need for rule management. To support it, new techniques must be learned and new tools implemented. Fortunately, pioneering companies have already discovered what these techniques are, and good commercial tools have emerged to support them.1 Rule management is a practical idea whose time is now!
The Knowledge Principle
What the company knows should be balanced with what it does.