The Business Meaning of Data Governance
There are probably many definitions of data governance out there, but any reasonable definition would have to be consistent with the general meaning of governance. A dictionary definition of govern is “to exercise authority over.” And authority is “the power or right to give commands, enforce obedience, take action or make final decisions.” If we are to truly govern our data, we must have systems and processes that ensure the data is consistent with the decisions of the people in authority.
From these definitions, we can see at least two elements involved in data governance at the basic level – who has the authority, and what are the commands and decisions of those people? I think the “who” would be the data authorities or owners somewhere in the business – it would not be in IT or someone in a separate data governance organization. Without trying to minimize the real challenges of trying to identify, legitimize and involve the particular business decision-makers in data governance, the focus of this article will instead be on the “what.” What are the commands and requirements of the decision-makers that good data governance must enforce?
The Use of the Data Model in Data Governance
Certainly, one of the requirements of the business is to have good data quality in the business systems. As data professionals, we are trained to address this requirement in a specific approach. First, we document the company’s business rules in a data model. We can then use that data model in two major ways: 1) as a guide to systems development and 2) to generate data quality reports. These efforts are certainly both valid and productive.
However, I would argue that even when companies successfully use their data model as described (which is not easy), they still have an incomplete implementation of data governance on behalf of the business owners. The implementation is incomplete in at least two respects:
- The data model does not and cannot capture all the data requirements of the business owners; and
- The data model does not and cannot capture the business process requirements for managing data as it relates to the business decision process.
The Limits of the Data Model for Describing Data Requirements
Data models document business rules with regard to entity relationships and entity attributes. We document whether a relationship with another entity is mandatory or not and which entity is the parent. We document whether an attribute is mandatory or optional, and whether the attribute has only certain permissible values (e.g., from a check table).
But the business rules do not cover when to create new instances of our key business entities. A typical business rule might dictate that all customer instances will have at least an “A” credit rating. But we don’t have a “rule” that covers the business decision to start selling to a particular customer (who must be determined to have good credit as part of the decision). We may have a business rule that says that new materials may only be of type 1, 2 or 3 with attendant specifications around the attributes and relationships of each material type. But we don’t have a rule that covers the business decision to start manufacturing and selling the particular new material XYZ.
So business rules captured in the data model don’t directly address this most fundamental example of a business decision. For most businesses, the business decisions that relate to entity instance creation are critical to business success. Businesses thrive or fail based on their success in creating particular new products, acquiring particular new customers, establishing new vendors, etc. Therefore, managing the master data creations that enable these decisions to be implemented quickly and accurately must be considered a top objective of data governance.
Further, even as an entity instance is created in the master data system, the data model does not specify which of several allowable attribute values is correct for a given entity. When we create a new customer entity, we know we have to include pay terms from the pay terms table. But what particular pay terms apply to this new customer? When we create a new material entity, we know that we have to specify how it will be planned for – its MRP type. But which MRP type should be applied to the particular new material?
The data model leaves similar gaps for entity relationships. For example, our data model probably requires that a material be extended to one or more plants. But which plants should a new material be extended to? Our data model may require that products be extended to customers so that the proper products can be offered to the customer during the sales cycle or so that total product demand can be calculated based on individual customer demand. But which products are associated with which customers?
To promote efficient operations, a business should capture both the basic entity information and the attribute values, as well as the required entity relationships necessary to make the data complete and useable. This integrated set of information is usually known at the time of the original business decision. The business knows not only the new customer but also the pay terms for that customer as part of its decision to engage with the customer in the first place – is the new customer worth special terms or will the customer get only the standard terms for the industry?
