TDAN: The Data Administration Newsletter, Since 1997

THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Subscribe to TDAN

TDWI
Dataversity
Business Analysis Conference Europe 2014
Data Governance Financial Services Conference
Data Modeling Zone
Data Governance Winter Conference

   > home > newsletter > article
 Printer-friendly
 E-mail to friend

Business Rules Validation

by Steve Hoberman
Published: April 1, 2004

Published in TDAN.com April 2004

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.

Go to Current Issue | Go to Issue Archive


Recent articles by Steve Hoberman

Steve Hoberman -

Steve Hoberman is a world-recognized innovator and thought-leader in the field of data modeling. He has worked as a business intelligence and data management practitioner and trainer since 1990.  Steve is known for his entertaining, interactive teaching and lecture style (watch out for flying candy!) and is a popular, frequent presenter at industry conferences, both nationally and internationally. Steve is a columnist and frequent contributor to industry publications, as well as the author of Data Modeler’s Workbench and Data Modeling Made Simple. He is the founder of the Design Challenges group and inventor of the Data Model Scorecard™. Please visit his website www.stevehoberman.com to learn more about his training and consulting services, and to sign up for his Design Challenges! He can be reached at me@stevehoberman.com.