We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


Business Rules and Data Rules: What's the Difference?

by David Loshin

Originally published November 18, 2010

With the Data Governance Winter Conference coming up, I thought that it would be worth discussing an aspect of data quality management that has come up in conversation with our clients regarding data governance: the difference between a “business rule” and a “data rule.” First, some background: I have always been a strong proponent of proactive data validation through formalized assertions specified as business rules. Providing a structure and an interface for defining these rules, one could then automate the validation by parsing and compiling the rules into executable services, as I described in my book Enterprise Knowledge Management – the Data Quality Approach.

At the same time, one of our service offerings includes processes for transforming business policies into data rules for monitoring compliance with defined business data governance objectives. This process also creates formalized business rules that can be integrated into automated services. So what is the difference between the business rules used for data quality validation and those rules used for data governance (and consequently, “compliance with policies”)?

Let’s look at a (simple yet contrived) example. Presume you are managing a call center, and you get reports detailing numerous metrics associated with ongoing operations. From a data quality perspective, you would like to institute some reasonableness tests on the aggregated data to make sure that data errors are not skewing the totals. Here are two examples:

  1. The average call length must not be greater than 4 minutes.

  2. The total number of daily calls must not be 10% more or less than the rolling average for the previous 60 days.
Certainly, errors in the data could account for triggering either of these rules. If either rule were triggered, a data analyst would be tasked with root cause analysis to determine what has caused the unreasonableness in the data. And if data errors are accounting for the skew, then the root cause analysis will hopefully identify where the bug is in the process, which can be corrected.

However, if there is not an error in the data, the triggering of either of these rules is indicative of an actual business problem. If the average call length has increased by a significant amount, or if the number of calls has jumped by 10%, perhaps there are emerging issues that require further investigation (for example, existing call scripts are not being effective in addressing customer concerns, leading to longer calls).

Basically, the same rule can be employed in two different contexts – both business and data quality, as can be seen in Table 1.

Table 1: Scenario Matrix

OK, then, so is it a data quality rule or a business rule? Perhaps we can look at this from the impact perspective. Table 2 characterizes the impact.


Table 2: Impact Matrix

If the rule is triggered as a result of a data error, that is certainly not good, but catching the error and fixing the process will prevent any further issues. If the problem is a business problem, that it worse, requiring a business analyst to take some action. The worst scenario is when there is a data problem that actually masks the business problem, in which the process of finding and fixing the data error does not alleviate the business issue.

Next, let’s consider the analysis effort, as is shown in Table 3.


 Table 3: Effort Matrix

If it is solely a data error, then the expended effort is solely a technical assessment to find the source of the error and then fix it. If it is determined that it is not a data error, then it might require more effort to figure out where the business problem is, and then change the process. When it is both a data issue and a business issue, the data problem will be evaluated and fixed, but the business problem remains, requiring the additional review to find the process failure as well. The sequence of events for each of the scenarios is shown in Table 4.


Table 4: Sequence Matrix

Reviewing this last table shows an interesting phenomenon: In any of the three cases in which there is any issue, the first action taken is to look for a data problem, even when there is not a problem with the data! Triggering the rule always means data quality root cause analysis, leading one to suggest that the primary intent of the rule is to flag a data issue and that the rule exists secondarily as a business policy compliance rule. Or, perhaps to answer the question more succinctly, the rule is a data quality rule unless no data error exists, in which case it reverts to being both a data quality rule and a business rule.

There are certainly more things to consider. We could adjust this analysis by considering additional variables associated with the four scenarios, such as frequency of occurrence, probability of occurrence, or whether there is conditional probability (such as whether the probability of the incidence of a business problem is increased when a data problem exists – hey, it could happen!).


Special Alert: Business problems are directly related to missed data quality expectations. Flawed information production processes introduce risks preventing the successful achievement of critical business objectives. However, these flaws are mitigated through data quality management and control: controlling the quality of the information production process from beginning to end to ensure that any imperfections are identified early, prioritized, and remediated before material impacts can be incurred. My new book, The Practitioner's Guide to Data Quality Improvement, shares the fundamentals for understanding the impacts of poor data quality, and guides practitioners and managers alike in socializing, gaining sponsorship for, planning, and establishing a data quality program. For more information, visit the book website at http://dataqualitybook.com for more information and special tips and tricks from me!

Recent articles by David Loshin


More BeyeNETWORK Articles


 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!