Many initiatives in IT are treated as projects with defined start dates and delivery dates. At the beginning of a typical project, everyone is bursting with enthusiasm, and by the end of it they are only too eager to get out. The deliverables are handed over to someone else, enabling the original team to move on to the next project. I have witnessed a number of business rules projects that follow this pattern and have come to the conclusion that "projectizing" the business rules approach in this way may not always yield the desired results. Projects dealing with business rules can work out well if they are individual components of a coordinated strategy. However, problems seem to arise when business rules projects exist in isolation with no linkages between them.

Let's Capture the Rules!

A common business rules project is to choose a business domain, or subdomain, and then go after all the business rules in it. Capturing and documenting the rules can take a lot of effort, but we now have tools, methodologies, and consultants that can assist in the process. Barring unusual factors, we can be pretty confident that a typical project of this kind will be a success. The results may be immediately useful to the sponsoring organization. Here is a typical list:

  • Different business users or organizational units may not have a clear picture of all the rules. At the end of the project they should have.
  • There may be conflicts in terms of incompatible business rules between organizational units. These conflicts should be resolved by the end of the project.
  • The way in which business rules actually work in computer systems may not be understood by business users. At the end of the project this should be clarified.

All this is very positive, but it only represents a snapshot of the rules at a particular point in time. The problems appear later.

Changing the Rules

Business rules are always going to be subject to change over time. This may not happen for all rules, and some business domains may change more slowly than others. However, any approach to business rules must take the possibility of change into account. Individual business rules come into existence at a certain point in time and expire at a later point in time. In between these two points in time, a rule may change. Thus, any one business rule can potentially exist as any number of versions in the finite lifetime of the rule.

The capacity of rules to change hits the project approach to them head on. Many projects accurately document a set of rules at a particular point in time. Then, as time passes, the rules change, but of course the project's deliverables are never updated. These deliverables then becomes subject to what I call the IT Documentation Uncertainty Principle which states that:

As soon as there is a reasonable doubt about one part of IT documentation, none of the documentation can be used without being verified.

In other words, a project that captures and describes business rules at one point in time, serves only as a starting point after enough time has elapsed so that there is a reasonable probability that the rules have changed. IT staff are always suspicious - and rightly so - about relying on outdated documentation. We should also remember that it is not only the underlying business that may change. Unfortunately, the ways in which business rules are implemented in computer systems may also change.

Changing Reference Data

Changing rules present a strong challenge to a standalone project approach to business rules, but it is not the only one. Business rules typically work in conjunction with reference data - also known as codes, lookups, constant values, etc. These pesky little tables usually consist of two columns (a code and a description) and contain only a few rows. They describe things such as Product Category, Order Status, Customer Type and are primary drivers of business rules. Like many business rules, they change slowly, but they do change. Because they are one of the least glamorous areas of IT they are typically ignored. For instance, I still see actual code data values entered directly into business rule definitions in rule documentation, instead of a meta data-based link to the reference data tables. This kind of denial about reference data includes denial about its capacity to change. Hence changes to reference data are another dimension of change that diminish the value of standalone projects dealing with business rules.

Business Rule Versions

The importance of business rules versions cannot be underestimated and needs a lot more space to treat it adequately than can be devoted here. However, one example may illustrate it. If we want to know how a particular value ended up in a particular column in a particular record in a database table at a specific point in time, we need to know what business rules were fired to populate the value in question. In the case of an audit, we may be looking at data from a year ago, or perhaps longer. The rules that operated then may well be different to the rules that operate today, and they may be different to the rules that we captured in a project two years back. The reference data that drives the rules may also be different today than a year ago. If we are to use the business rules approach to audit data, then we must be able to handle versions of business rules (and versions of reference data).

Unless we structure business rules projects so that they are part of a larger approach that captures changes to business rules over time, then the deliverables of these projects are going to have a rather limited shelf life. Organizations are undertaking business rules projects, often without a clear idea of why they need to do so. If the deliverables of these projects lose their value quickly with the passage of time, the danger is that the business rules approach may be discredited in the minds of senior management. What we need is a clear understanding that any approach to business rules must recognize capacity of rules to change and must track these changes over the long term.