When you hear some talk about Data Governance, it is hard to decipher whether they’re really talking about Data Governance or if they’re really talking about Data Management or some ambiguous conglomeration of the two.
The DAMA Dictionary of Data Management defines Data Governance as “The exercise of authority, control and shared decision making (planning, monitoring and enforcement) over the management of data assets.” DAMA has identified 10 major functions of Data Management in the DAMA-DMBOK (Data Management Body of Knowledge). Data Governance is identified as the core component of Data Management, tying together the other 9 disciplines, such as Data Architecture Management, Data Quality Management, Reference & Master Data Management, etc., as shown in Figure 1.
Figure 1 – DAMA DMBOK Data Management Functions
Many people are completely on-board with Data Governance – up to the point of working collaboratively across business units, where only roadblocks are envisioned. Data Governance is definitely disruptive but in a positive way (if approached properly). It does entail change – including organizational change (e.g., Data Governance Council, Data Stewardship Coordinating Committee, etc.). We’re not talking about a guerrilla approach to Data Governance where some visionary, but under-authorized data architect tries to effect change using influencing skills!
But what exactly is meant by exercising “authority, control and shared decision making … over the management of data assets” and what are some practical ramifications of this? Exactly who needs to exercise “authority, control, and shared decision making?”
Much (but not all) data is enterprise in nature – it is often CRUD’ed (Create, Read, Update, and Delete) or shared with multiple applications in multiple business units. In these cases, the data needs to meet the needs of multiple systems. However, very often near-term pressures, unwillingness to share data (as Len Silverston calls it “data mining” i.e., it’s “my” data), or poor data modeling practices dictate the structure and format of the data to meet the immediate needs of the application and so we have the numerous information silos and integration efforts. Data Governance is obviously needed in order to exercise authority to minimize whenever possible these costly information silos (each often requiring more licensing, more hardware, more labor (duplicative analysis, modeling, management)) and the resultant costly integration efforts.
Data is a non-fungible (i.e., irreplaceable) asset – one piece of data is not equivalent to another piece of data (e.g., a record about one customer may represent a platinum customer, and another record might represent a bronze customer…). Clearly if we lose, can’t find, can’t understand, or can’t integrate valuable enterprise data or if it is of questionable quality – the maximum value of the data is not realized, leading to a loss of business insight or sub-optimal operations. At the end of the day, we govern data not for the sake of the data, but for the sake of the business!! Therefore, the business must play the dominant role in Data Governance – if Data Governance is driven by IT, this is a recipe for lack of business involvement and Data Governance failure. For “shared decision making,” data governance must work collaboratively across business units.
In my next article I will talk about some organizational structures that enable Data Governance and its sub-discipline – Data Stewardship.