Three Tips for Better Data Definitions

If business or IT users insist that their definition is good and everyone knows what they mean when in fact that is not the case, the strategies below may help.

1. Provide examples of unclear vs. clear definitions

Users who are intimately familiar with their business process and supporting systems may not understand the point of specifying exactly what they need. To them "the ID of the customer" is a perfectly acceptable definition of "Customer ID." Or, the IT representative may give a definition that works for them but no one else, such as "the primary key of the customer table". It will help both to see examples of what is needed in order to have a workable definition to support data warehouse population and use of the data.

Unclear:

Customer ID: The ID of the customer

Clear:

Customer ID:  

The 10-character code that uniquely identifies a customer for our business. 
This code is displayed on all customer invoices. Customers and customer 
service reps use this code to resolve service issues. Finance uses this code 
to track customer sales performance by Customer ID. Sales uses this 
code to identify existing customers and products customers are buying.

The code consists of the following:

Character 1: either I (for customers internal to thecompany) 
or E (for customers external to the company)

Character 2: either U (for U.S. customers) 
or N (for international customers)

Characters 3 – 10: system-generated numeric ID that is unique to that customer

Beyond being ambiguous, the “unclear” definition hid the fact that the Customer ID contains embedded data that might otherwise have been overlooked by data modelers.

 2. Understand what the business user wants to do with the data

If you are still stuck with an incomplete definition, ask the primary business users to explain why they need that particular data element and how they use it in their work. Perhaps the data element is not being used, in which case it may be best not to bring it in to the data warehouse. If it is being used, understanding how the business uses it often will allow you to refine their definition into something more meaningful and workable.

For example, if your business definition of order type is “what kind of order it is”, asking how it is used could yield valuable add-on information: “We use order type to track sales results for our monthly sales reports. John is responsible for software orders, Phil handles hardware orders, and Elizabeth owns service orders.”

Armed with that knowledge of use, you can expand the definition of order type:“Order type: the sales category of the order. Must be one of the following: software, hardware, service. Used to group sales by order type for monthly sales reports.”

3. Bring all stakeholders together to review definitions

If you are not fully familiar with the business data you are documenting, you may not be able to catch all vague or poorly articulated data element definitions. And if you take the business users’ word that their definitions are clear, you may end up with trouble down the road when you use the definitions to populate the data warehouse and provide the data for business users in different areas of the organization.

The solution here is to have all stakeholders confirm definitions once you draft them with the primary business users. With input from all business and IT users who use the data, you can ensure that the definitions provide enough detail and clarity that all stakeholders understand the meaning and use of each data element.

--

Excerpt from "Data Definitions: Speaking the Same Language", Tom Krieger, Information Management Print Edition, July/August 2010