Larry was at the headquarters of one of the largest industrial organizations in the U.S. and his task, on behalf of a business rules technology vendor, was to understand why this client had decided to replace his client’s technology with a package. The decision could not have been taken lightly – this was a custom built order processing system, a huge system by any measure. It had been built but ten years previously at a cost that ran into eight figures. By the vendor’s count it contained over 20,000 rules. Why would the client take the extreme case of replacing the system that they themselves, only a short time previously, had spoken about with high praise?
Turns out, the problem lay in the rules! “We have lost track of our rules” the client explained “the business doesn’t feel able to manage the rules in the system.” Larry understood immediately, and they really didn’t have to spend the rest of the day giving us the details of the problem. We have other clients who discover that managing 1,500 business rules is a daunting task. Heck, one client with but 600 business rules cried “Uncle!”
The hard, hard truth is that managing business rules is very, very difficult. Period.
Now we know that we preach about the value of business rules, and we glibly talk about them as “levers” that management can use to manage their business. We plead as guilty as others because it certainly seemed to make good sense. But one should only pull a lever that is appropriately labeled, and when the consequences of pulling that lever is well understood!
Here is the reality: the business rules projects that have worked well, that have inspired our commitment to the discipline, and which we can point to as delivering on the promise of business rules, are those where the business rules have been abstracted into a form that is recognizable, and to a level of granularity that is manageable by the business people.
One of the most successful business rules project in Larry’s professional experience was implemented some 14 years ago at a financial services firm in the mid-west. Their system was years’ ahead of its time and it transformed the company strategically, helping it become a leader in its primary market. But when we asked them if they would present at a business rules event, they were mystified – “but we don’t do anything with business rules” was the response. But of course they did – they were simply not aware of the underlying business rules engine that drove the technology. Their business rules were abstracted into, and exposed as artifacts that had a greater granularity, and a more meaningful context in their business than individual business rules. Consequently they were managing far fewer that the 26,000 rules that we counted in their system. In fact they viewed their system through the prism of what they called “bricks” – about 100 or so sets of logic that were grouped in ways that made sense to the business. These bricks today would be called decision services, each having all the characteristics that define a well architected web service.
These guys were ahead of their time, but their approach was one of the several that served as inspirations for Decision Management (DM), a new discipline that promises to deliver what we haven’t been able to achieve with business rules.
Of course, we say “ditch your business rules” with our tongue firmly in our cheek. But today we no longer ask people to think about managing individual business rules. We understand that managing at that fine level of granularity is challenging because of the multiplicity of the number of rules across the enterprise. Individual business rules are seldom of much business value by themselves without considering many other related business rules that almost certainly impact them. We also believe that the days of organizing business rules into natural language sentences are over, because they have proven to be unmanageable in that form. Business rules, sans context and structure, are fairly meaningless or of little management value by themselves.
What do we mean by “context” and “structure”?
Let’s start with context. By this we mean the context of the business decisions within which the business rules reside.
Take the case of a business rule related to determining the preferred status of a customer. It would seem to be simple to express such a rule in a natural language, particularly with the well accepted forms of rule grammar that we have today. However, the fact is that the determination of customer status can be very complex, involving not one but perhaps tens of business rules, even – in some cases – hundreds of rules. Let’s take a naïve example. A business rule may say:
“A customer is a preferred customer only if all the following are true:
- Customer’s account is currently in good standing
- Customer has accumulated purchases in excess of $5,000 in the prior 12 month period”
This sounds pretty straightforward. Until you learn, as you dig deeper that actually the customer’s preferred status hinges on several more unrelated items (the grammar we are using in this example does not indicate, with the use of the words “only if” that these things being true, then the customer is preferred: it merely means that if these things are not true, then the customer cannot be preferred). It may turn out that there are a slew of marketing rules to which the customer may have to comply to be considered preferred, and then there may also be a geographic issue that relates to preferred customers. There may also be business rules in several other areas that touch upon the customer’s preferred status, such as supplier agreements, and long term commitments from the customer and so on.
Well, the problem may be solved – giving the rule “context” – by gathering into one group all the business rules that relate to the customer being preferred . You could call that group a rule set, or better yet, a “business decision”, and then you can manage that business decision as a single unit. So a business decision is a context for business rules, enabling you to see the business rules with all business rules that together reach a single decision.
So much for context. What about structure?
Well, just putting the business rules into sets that we conveniently call business decisions does not solve the problem of complexity. Turns out that some of the rules used to determine validity for the preferred program are also used to determine the amount of money that may be provided for co-op marketing, or other purposes. So many (perhaps even most) business rules may belong to several sets (or business decisions). What happens when the business rule needs to change in one business decision for a particular business purpose, what is the impact on the business in the other sets in which the business rule is used?
When business rules reach into the thousands then the complexities of this interwoven logic becomes fearsome, and problems abound. How do you test the business rules for completeness? How can you be sure that there are no duplicates? How can you make sure that there are no rules that contradict one another?
The answer to that problem lies in structure.
Think about the problem of data. Unstructured data is chaotic, and difficult to use. So it needs to be structured. Everybody – with very few exceptions – uses a specific model to organize data: this is called the Relational Model. This model enables the data to be “normalized” – that is they are reduced to more desirable structures – and soon enough it becomes easier to access, to understand, to manage. The Relational Model has become universal because it organizes the data based on the inherent structure of the data, so everybody pretty much understands it, and feels confident in accessing the data in such a structure.
So the answer to the problems with business rules lies in a model for business logic that has a structure that is as elegant, as simple, as the Relational Model is for data. A model that will organize the logic, based on the inherent structure of the logic itself, into structures that are normalized and stable, and that make sense to the business person.
Such is the purpose of the Decision Model, a model proposed by us in our new book called “The Decision Model: A Business Logic Framework Linking Business and Technology.” We believe that the model meets the goal we set out to achieve, and will enable business to manage the large aggregates of business rules – or, as we prefer to call it, business logic – that inherently exist in organizations today but are unstructured and unmanaged. The model creates both a context – that is, it combines a set of business logic into groupings that make business sense – and a structure that is normalized and stable over time. One significant value of the model is that it can be represented visually, promoting a shared understanding of the logic just as a process model promotes shared understanding between all stakeholders.
Look at the diagram in Figure 1.
 |
Figure 1 Sample Decision ModelAdapted from: The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.
This diagram gives you the top level view of the Decision Model. A Decision Model diagram contains only two kinds of shapes. One is the octagon representing a business decision and the other represents a Rule Family. The name of a Rule Family is always the name of its conclusion fact type and always appears above the solid line within the Rule Family shape.
You can see from the business decision shape in Figure 1 that this is a model of “Determine Policy Renewal Method.” This business decision is important to the success of the insurance company client: the higher the percentage of policies that they can renew automatically, the less out cost, and the better the service they can provide their customers. However, the quality of underwriting can’t be compromised. So in order to balance these considerations, you may use the Decision Model to manage this business decision. Here you see a very important characteristic of a business decision: it is, we say, a conclusion that is based upon fact, and which the business is interested in managing.
A Decision Model always begins with the business decision, which in turn always connects to one Rule Family, called a Decision Rule Family. The Decision Rule Family has a conclusion fact type (or term) matching the business decision. Consequently, the Decision Rule Family in Figure 1 is called Policy Renewal Method which is its conclusion fact type.
A Rule Family always contains only one conclusion fact type, which is why a Rule Family has only one name. However, a Rule Family also contains condition fact types leading to the conclusion. These always appear below the solid line. So, the Rule Family for Policy Tier Within Bounds contains two condition fact types: Policy Tier and Policy Discount. This means that the business logic in this Rule Family tests these two fact types to determine a value for its conclusion fact type, Policy Tier Within Bounds.
Note that Policy Discount appears between the solid and dotted line, but Policy Tier appears below the dotted line. This is important. The values for Policy Tier are simply available as raw data, from a database or web page. So this fact type appears below the dotted line. Yet, the values for Policy Discount are determined by other business logic. Therefore, this condition fact type relates to another Rule Family having this fact type as its conclusion fact type. So, Figure 3 contains a Rule Family whose conclusion fact type is Policy Discount and there is a line connecting these Rule Families. This connection is an “inferential relationship.” It means the Rule Family called Policy Tier Within Bounds is dependent on the Rule Family called Policy Discount.
Because the Decision Model diagram reveals only the inherent structure of its business logic, not its details, we need a way to expose the details.
 |
Figure 2 Rule Family Structures in the Decision ModelSource: The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.
The details are in the Rule Family table and consist of rows conforming to its condition and conclusion columns.
Figure 2 shows two inferentially related Rule Families and their Rule Family tables. The Rule Family for Policy Tier Within Bounds has two condition fact types, each of which has its own column in the Rule Family table under “conditions.” The conclusion fact type has its own column under “conclusion.” The Rule Family table is populated with combinations of conditions that lead to all the and permutations for reaching conclusion values. You can add, delete, or update rows without making changes to the Decision Model structure. You can also a guess at the Decision Model structure before knowing all business logic. This is extremely valuable for agile projects.
At first glance a Rule Family look like a conventional decision table, but in fact it is a highly normalized structure that rigorously complies with the 15 Decision Model principles to ensure that it is stable and contains logic that has both inferential and business integrity.
The two sample Rule Families in Figure 2 are good examples that you can use to explore this briefly. If you look at the Decision Rule Family for Policy Renewal Method, you can read the business logic statement in the first row as “If (or when) the policy manual override is yes, then the renewal method is manual.” Or you could read row three in the Rule Family for Policy Tier Within Bounds to say “If the policy tier is less than or equal to 2, and the policy discount is greater than 20, then the Policy Tier is not within bounds.”
It may be interesting for readers experienced in business rules (and perhaps even – or especially! – those that are not) to analyze the Rule Family for Policy Tier Within Bounds shown in Figure 2. We hope that only a brief analysis should show you that this Rule Family is incomplete, and is clearly missing rows. The value of the principles of the Decision Model is that they give you a set of tools to analyze the logic of the Rule Families to a much greater degree than this simple example. They allow you to analyze populated Rule Families for completeness, inferential integrity, and to normalize them to the three levels of normalization. This ensures that the structures are:
- Predictable: Two different analysts sent to gather business rules from a business group arrive at an identical set of business rule structures, and two different programmers sent to implement those rules into code would arrive at identical code structures;
- Stable and Normalized: A particular business rule belongs in only one place and in the right place in the decision model structure, ensuring the integrity of the Decision Model.
- Maintainable: If the business rules were changed, or some business rules were added to (or removed from) a given decision, often changes are made as simply as data rows are added to (or removed from) a data table;
- Aligned with Business: Correlated to business motivations and metrics
The benefits that flow from using the Decision Model to separate the business rules, and manage them, are very significant. They extend into many areas of management and information technology practice, such as BPM, decision management, architecture, and software development.
Yes, it is true that managing your business rules is difficult: but managing your decisions is practical, could be very rewarding for both business and IT.
