One of the more challenging areas in Business Intellegence and Data Warehousing is understanding how to apply tests to data that has been transformed, to prove we have delivered a correct result.
It can be as simple as proving that we are presenting the right revenue, cost and profit numbers for a period, through to proving we have provided the correct number of customer records after applying complex business rules to conform customers records which have been sourced from 8 disparate source systems.
– clarity of the rule
If we ask a business user what data result we should use to prove both of these scenarios we are unlikely to get an answer. They find it hard to give a categorical number for these, in fact that is why we are often building this capability because they cannot get the numbers easily and repeatably.
And that is often the catch 22 situation, we won’t have that number until we have produced it, but we can’t check it against itself. Or can we?
– go with what we do know
In these scenarios we can use a Champion vs Challenger approach.
We set the best guess as the Champion result and then let anybody Challenge it. They can challenge the rule or the result. If after joint investigation there is agreement to change the rule, then the new rule becomes the champion, which of course can be challenged at anytime.
By doing this we can iteratate these rules when required to end up with a mature and hardened set of rules that consistently produce an agreed “single source of the truth” result.
– Scenario 1: Business Rules Defintions
Often when defining business rules with our stakeholders we get nervous as it seems they do not have a high level of confidence when articulating the rule. We become worried that after a lot of work creating code to apply this rule, they or somebody else will decide that the rule needs to be changed as it is not quite correct.
If we have spent a secondary amount of time manually testing these numbers, the testing rework alone of these changes will be substantial.
This is why of course we need to utilise Agile Data Engineering techniques [[automation??]] to apply these tests and rules, as well as ensuring we know in which data layer these rules are applied to ensure we can easily change them.
We might profile the data and prototype the rule to present the prototype results back to the stakeholder to confirm the rule.
– rules are best guesses that can be challenged
Neither of these approaches deal with the issue of other stakeholders challenging the rule and the conversations and rework that results.
In the past we would spend a substantial amount of time trying to lock these business rules down. Perhaps forcing a data governance style forum to sign these rules off as “gospel” to never be changed. AgileBI is all about enabling and dealing with change so this approach does not fit with our AgileBI approach.
The AgileBI approach we now use is to treat the first business rule definition we get as a Champion rule. We then build the rule as quick as we can and define it as the Champion rule. Then in following iterations within a sprint, or in future sprints this rule can be changed, when a challenger rule is determined to be a better fit for the business need.
One of the main benefits of this approach and terminology is that the stakeholder becomes more comfortable that they are not writing the business rule in stone, for it to become a commandment that can never change for all eternity.
They understand the Champion rule is the initial “guess” at what the rule should be, and can be challenged at anytime. This often will result in the stakeholder providing these rules much faster, as there is less risk in doing so. This results in the AgileBI team being able to apply the rule quicker and show the stakeholder the results of the rule using real data. Which enables more iterations of the rule in a sprint.
[[challenger model, what somebody else thinks it should be]]
– Scenario 2: Testing
[[dont know what the answer is for a test for a business rule]]
– Scenario 3: Master Data Definitions
[[cant agree what business rule to apply as the corporate standard]]
{{active customer, marketing active, finance active, risk active}}