In this month's installment of my data stewardship series, we will examine the most common data stewardship activities.

The specific activities of the data stewardship committee will vary from one organization to another and from industry to industry. No two data stewardship committees are exactly the same; however, the following are the most common data stewardship activities: data domain values; data quality rules, validation and resolution; business rules/security requirements; business meta data definitions; and technical data definitions.

The data stewards that work on these different activities will be primarily working with meta data; however, there will be occasions when they may need to work with actual data. In the following section, I will walk through these common data stewardship activities and provide a set of guidelines and best practices around them. Also, I will discuss the typical data stewards that accomplish these tasks. It is important to note that sometimes there are people that are highly knowledgeable on the data and the business policies around the data, even though they do not belong to the particular stewardship group that I mention for the activity. For example, in your company there may be technical stewards that are as knowledgeable on the business policies and data values as any of the "official" business stewards. Thus, even though I state in my guidelines that the business stewards should be creating the business meta data definitions, you would obviously want these technical stewards working with the business stewards to create the business meta data definitions.

Additionally, for all of the activities discussed, the chief steward will play a critical role in ensuring that these activities are properly completed. A good chief steward will make sure that the technical and business stewards work thoroughly and expediently. The chief steward understands how easy it is for these groups to fall into "analysis paralysis" and will act as a project manager/guide. Most importantly, the chief steward will aid these people in any needed (and you will need it) conflict resolution for the different data stewardship tasks.

Once the business stewards have defined their key data attributes, they need to define the domain values for those attributes. For example, if one of the attributes is state code, the valid domain values would be the two-character abbreviations of the states (e.g., CA, FL, IL, NY, etc.).

As with all of the data stewardship tasks, this meta data will be stored in the meta data repository. It is highly recommended that a Web-based front end be developed so that the business stewards can easily key in this vital meta data.

In many cases, data modelers have inputted attribute domain values into their modeling tool (e.g., Erwin, Silverrun, System Architect). If this process has occurred in your company, you can create a process to export that meta data from the modeling tool into the meta data repository. This will provide the business steward a good starting point in the process to enter domain values.

Data quality is the joint responsibility of the business and technical stewards. The business steward defines data quality thresholds and data error criteria. For example, the data quality threshold for customer records that error during a data warehouse load process may be two percent. Therefore, if the percentage of customer records in error is greater than two percent, the data warehouse load run is automatically stopped. An additional rule can be included that states if the number of records in error is one percent or greater but less than two percent, a warning message is triggered to the data warehouse staff; however, the data warehouse run is allowed to proceed.

It is the responsibility of the technical steward to ensure correct implementation of the data quality rules. In addition, the technical steward will work with the business steward on the specific data quality threshold and data error criteria.

Business rules are some of the most critical meta data within an organization. Business rules describe how the business operates with its data. A business rule will describe how the data values have been derived, calculated, if the field relates (cardinality) to other fields, data usage rules/regulations and any security requirements/limitations around a particular entity or attribute within a company's systems. For example, a healthcare insurance company may have a field called "POLICY_TREATMENTS." This field may list the specific medical treatments that a policyholder may have undergone. The business rule for this field could be that it is an alphanumeric, 20-byte field, with a "system of record" from "System A." In addition, there may be security requirements on this field. Most health insurance companies provide coverage to their own employees. Therefore, the security requirements for this field may be that the IT department is not allowed to view this field or associate it with any fields that would identify the policyholder. When security rules such as these are broken, the corporation experiences a great deal of legal exposure.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access