Top 3 validations to correctly capturing business rules in your design
“What do you find most difficult about modeling?” I was asked this question while walking briskly to my Data Modeling Workshop at the Boston TDWI World Conference this last August. Not
an easy question to answer … especially before a strong cup of coffee. I went through in my mind my 10-step approach to building a logical design, and after some thought replied,
“Correctly capturing the business rules”. Later that day I gave additional thought to this reply, thinking about where the difficulty might lie. Phrasing this in a more positive way,
what validations or affirmations are required to ensure our design captures the right rules? After reflecting on a number of recent projects, I believe the following 3 validations need to be
performed to make sure we’ve designed the right business rules:
- Validate rules inherited from source or replacement systems
- Validate “dream versus reality” in the eyes of the business
- Validate the appropriate point of time and time span
In this article I will briefly discuss each of these validations with the goal of increasing your awareness and therefore ability to act and improve the accuracy of your resulting design. I will
also share two activities that can be performed to help with these validations.
Validate rules inherited from source or replacement systems
In building a business intelligence solution we tend to copy rules from the source systems. Similarly, in replacing legacy systems in our companies with new homegrown systems or ERP (Enterprise
Resource Planning) packages, we tend to inherit many of the rules in the systems we replace. Sometimes copying a rule is the right thing to do, and sometimes not a good idea. The point here is we
need to validate the rule, and if the rule is not correct, we need the correct rule. An example of this that I would imagine many of us have faced (and it’s a simple example but it
illustrates this point), is when a source system only allows you a certain number of something, and you as the designer can either inherit exactly the same number of this something or incorporate
more flexibility into your design. A source system might allow an employee to have at most 8 dependents for example. Should we copy this system rule, or change it to allow 9, 10, or 100? In some
cases, there is a heavy IT focus on copying over whole structures from existing systems which can lead to incorrectly assuming what holds today will hold in the new system as well.
Validate “dream versus reality” in the eyes of the business
Have you ever met with a business person or functional analyst during the analysis and design phases and heard something like “We would like an Order to exist without an Product.” The
key word here is ‘like’, which could imply any number of things such as:
- It doesn’t work this way today but it might in the future
- I think it works this way but I’m not sure
- This is the way the business would like it to work
This is where a lot of the modeler’s analysis and detective skills come into play. I have seen each of these situations a number of times, but most recently in the ERP realm when a very large
pre-built software package comes into our companies and strongly “encourages” the current business processes to change.
Validate the appropriate point of time and time span
In working on a large data warehouse project recently, we were pretty confident that we had our rules on sales correctly defined…that is, we were confident until we starting loading data
pre-1998 and noticed how different the rules actually were! These surprises tend to present themselves more often than we would like in data warehousing, because of the timeframe of data we
generally load and the level of integration required. What do we do in this case? Do we:
- Only bring in data after a certain date where the current rules have taken effect (and risk not answering certain business questions on trending)?
- Bring in everything and change the rules overall to the lowest common denominator (and risk introducing certain data quality problems with a possible lose of referential integrity)?
- Bring in everything and have separate structures and logic for each set of rules (and risk introducing too much complexity and running over budget)?
Each of these solutions have their pluses and minuses, and luckily I don’t have to pick one here! (The answer anyway, as you might expect, is “it depends”). This section’s
purpose is to make you aware that these situations exist, and be more proactive to catch these during analysis and not during development.
Now that I’m aware of these validations, what next?
Good question. Luckily each of these validations can be performed with the same two activities: prove or disprove the rule with real data if appropriate, and get an actual person to sign off on
what they say the rules are. I have found actual data to provide the greatest numbers of “oooohs”, “I didn’t know thats”, and “wows” during a project. Try
to get your hands on some actual data and try to break the rules. If the business believes an account belongs to one or more customers, try to find an account with no customers. Note that you might
find yourself searching for default values here. For example, sure every account has a customer, but there are a large number of accounts whose customer name is “Not Applicable”! Make
sure you have an actual person sign off on these rules, similar to the process taken during user acceptance testing…but do the rule validation as early as possible in the design. Validate
these kinds of rules with someone knowledgeable in the business. Try to pick someone with broader business expertise than just a specific system or department. Make sure you’ve identified an
individual. Somehow having a person’s name, and not a department or several people’s names, associated with a rule tends to produce higher quality results.
This article discussed the three rule validations required to improve the accuracy of your model, and ended describing two activities that can help perform these validations. Although the work is
challenging and time consuming to validate the rules, your reward is a stronger and more accurate design and greater knowledge for yourself as to how the business really works.
