Data Stewardship Activities
Last month I described three of the most common data stewardship activities:
- Data Domain Values
- Data Quality Rules, Validation and Resolution
- Business Rules/Security Requirements
This month I will discuss the two most common data stewardship activities: Business Meta Data Definitions and Technical Data Definitions.
Business Meta Data Definitions
One of the key tasks for the business stewards is to define the business meta data definitions for the attributes of a company. A couple of years ago a friend of mine shared with me the following quote by Daniel Davenport:
“The greatest problem in communication is the illusion that it has been accomplished.”
I don’t know anything at all about Mr. Davenport or if he even knows what meta data means. However his quote succinctly sums up the need for business meta data definitions.
Typically it is wise to begin by having the business stewards to define the main subject areas of their company. By subject areas we mean the “nouns” of the corporation, e.g. customer, product, sale, policy, logistics, manufacturing, finance, marketing, and sales. Typically companies will have between 25 – 30 subject areas depending on their industry. Once your business stewards have defined their subject areas then each of these areas can be further drilled down. For example, for product your company may want to distinguish between the different lines of business or by subsidiary.
For some data elements they will require calculation formulas of some sort. For example, your company may have a data attribute called “NET_Revenue”. NET_REVENUE may be calculated by subtracting “gross costs” from “gross revenues”. Any calculation formulas will need to be included in the business meta data definitions.
Once the key data elements have been identified then the business stewards can begin working on writing meta data definitions on the attributes. The process for capturing these definitions needs to be supported by a meta data repository. The repository would have meta data tables that would have attributes to hold the business meta data definitions. In addition, a web-based front-end would be given to the business stewards to key in the business meta data definitions. The repository would capture and track these meta data definitions historically. This historic tracking is accomplished via having “from” and “to” dates on each of the meta data records. Also a meta data status code will be needed on each row of this meta data. This status code would show if the business meta data definition is “approved”, “deleted” or “pending approval”. This code is important because it is a\a poor policy to delete meta data rows. The second you delete a row of meta data that the user inputs they will want it back.
When the first business meta data definitions are entered it is common to mark them as “pending”. This allows the business data stewards to gain consensus on this elements before moving their status to “approved”.
Technical Meta Data Definitions
The technical stewards are responsible for creating the technical meta data definitions for the attributes of a company. It is important to understand that technical meta data definitions will fundamentally differ in form from business meta data definitions. As business meta data definitions are targeted to the business users, technical meta data definitions are targeted for an organization’s IT staff. Therefore it is perfectly acceptable to have SQL code and physical file/database locations included in the technical meta data definitions.
Usually it is too much work to have the technical stewards list out all of the physical attributes within the company. It is wise to begin by having the technical stewards list out their key data attributes. By initially focusing on the core data attributes it helps the IT department to have their technical meta data definitions on their most important data attributes. Once your technical stewards have defined these initial physical attributes they can now start working on the remaining attributes.
The process for capturing these technical data definitions will be a mirror image of the process to capture business meta data, in fact the web-based user screens should look very similar. Also the same functionality which I described in the previous section (from & to dates, status codes, etc.) should also be included.
Once both the business and technical stewards define their meta data definitions what occurs in 100% of the situations is that discrepancies will be discovered between the definitions. For example, the business stewards may define “product” as any product that a customer has purchased. The technical stewards may define “product” as a product that is marked as active. These two definitions are clearly different. In the business stewards definition any product (active or inactive) that is currently on an open order for a customer would be valid. Obviously, the IT staff will want to work with the business users to repair these hidden system defects.
