Chapter 12 Data Governance Tools – Activity Matrix

The Governance Activity Matrix is similar to the Common Data Matrix in that it is a two-dimensional matrix that can be customized for use specifically by the organization implementing data governance. Implementing this tool may be completed in many different ways, and like the Common Data Matrix, the cost of developing and using this tool is minimal.

The idea of the governance activity matrix is to cross-reference the steps of a process dealing with data with roles you identify for inclusion in your data governance program. This may sound simple, but you need to consider several things when using this tool.

The first consideration is properly naming the tool and the processes that are governed. The second consideration is what processes will be governed and what it means to govern a process. The third consideration is what information will be collected and used within the tool itself.

Avoid the Term “Data Governance Process”

The term “data governance process” contradicts everything about the non-invasive approach to data governance. First and foremost, governance can be applied to any process. Second, just because processes become governed, they don’t become data governance processes.

By calling them “data governance processes,” we imply that the processes are followed purely because of data governance. But this is typically not the case at all. In fact, you can view almost any process as a form of governance itself, as long as the process is followed.

An ADLC or an SDLC (Application or System Development Lifecycle Methodology) is a form of governance for the development of an application or system. This methodology states the steps to follow in the development, who’s involved, the decision that’ll be made, the outcome from each step of the methodology, and other things. ADLCs have been around as long as there have been data and systems. Some organizations follow this methodology more closely than others.

The agile development community often appears at odds with the data management community; bringing the two together will be the focus of my next book. But again, the agile approach is, in itself, another type of governance.

The point is, we should not rename the methodology as a “data governance methodology” simply because we appropriately focus on the data according to the steps and involvement throughout the process.

The same holds true for the process of sharing data, the process for requesting access to data, or the process of deleting data. Many organizations have processes for how they do these things. The processes need not to be relabeled as “data governance processes.” This label implies that data governance is the reason why we have these processes in place in the first place.

If we want people to know we are non-invasive in our approach to data governance, the last thing we want to do is label processes as governance processes. Rather we explain why we avoid calling them governance processes and that we can either follow these processes formally or consider them for what they are.

Processes to Govern

Organizations determine, in several ways, which processes will be governed or fall under the auspices of data governance. For example, governing the ADLC is one way of building the data focus into every step of new development. Governing data-sharing agreements is another. Governing how we solve data issues may be a third way.

The first question to ask may be, “How do you want to apply data governance at your organization?” Do you want to apply governance proactively by building it into a day-to-day process? Or do you want to build governance into the way you solve issues and address problems? The truth is that most organizations want to do both. In any case, most organizations start reactively by building governance into improving the quality and value of data and slowly building governance into their daily routines.

Proactive Data Governance

The example below demonstrates how an organization built data governance activities into the steps they were following to systematically restructure data in their data warehouse. In this instance, you can see that the activity matrix highlighted the steps of the repeatable process down the left side of the matrix while including the different roles associated with the data governance program across the top.

In each block where the process bisects with the role, you’ll see a description of what the person in that role accomplished during that step of the process. In this example, the amount of time that role is expected to play in each step of the process is defined with the period of time that role is expected to be involved.

DG Roles & Level (>) Data Dictionary Valid Process (v)	Estimated effort	Data Governance Team (DGT) Support Level	Information Technology (IT) Support Level	Data Governance Council Strategic Level	Data Domain Stewards Tactical Level	Data Stewards Operational Level
1. Organize & rationalize 250 reports associated with data warehouse to determine 100 most used & important data element needs.	August– September 2014 (6 weeks) To analyze 250 reports to identify 100 enterprise data elements for data warehouse restructure.	Manage the organization & rationalizing of 250 data warehouse reports. Identify data element usage on the reports to determine 100 most important data element needs. (16 hours per week per 2 people)	Supply list and access to technical data warehouse reports. Participate in rationalizing of the reports & identifying of data elements. Record definition of data elements in business glossary. (8 hours per week per 2 people)	Approve list of most important data elements. (1 hour to review and approve data elements)	Work alongside DGT to rationalize all data warehouse reports to identify most important data elements. (8 hours per week per Subject Area)	Supply list & access to data warehouse reports. Participate in rationalizing of the reports & identifying of data elements. Record definition of data elements in business glossary. (8 hours per week per Business Unit)
1.1 Define Selection Criteria: Reports group, Frequency of use (daily, weekly), data elements used (commonality), criticality, with different results between Business Objects® versions.
1.2 Define and document: objectives, goals and expected benefits of restructuring the data elements.
1.3 Define templates and procedures to get the final results.
1.4 Define the top ten most critical reports (Quick win).
1.5 Set up success criteria for these reports.
1.6 Identify the data analyst to contribute to the record definition (producers/users of the reports chosen).
1.7 Agree and Close the “planning” to finish this “project”
2. Analyze & record definitions in the business glossary. Identify list of data elements that will be included in the data warehouse restructure.	September – October 2014 (6 weeks)	Manage the analysis of the data element definitions. Document the data warehouse restructure requirements and the enterprise data element standards. (16 hours per week per 2 people)	Provide technical and systems information about the most important data elements. (8 hours per week per 2 people)		Provide enterprise business view of most important data elements. Define and document the data element standards in the business glossary. (8 hours per week per Subject Area)	Provide business information to include in the definition of the most important data elements. (8 hours per week per Business Unit)
2.1 For each report: Identify the results.
2.2 Identify the data elements that appear.
2.3 Match the existence of the definition in the data dictionary
2.4 Validate the definition or gap (by adding a new one…).
2.5 Close the report data element definitions.
2.6 Introduce the new definition for approval, then add to data dictionary.

Reactive Data Governance

Many organizations begin their data governance programs by solving known data issues. And they provide a way for people of the organization to record and communicate problems they have with the data they define, produce, and use.

These organizations often standardize the processes they follow to resolve their data issues and to apply governance to these reactive processes.

The example below demonstrates how one organization defined the steps of the process to resolve data issues and to cross-reference the steps someone would need to be involved with using concepts borrowed from the commonly referred RACI assignment matrix. In this way, the organization identified which role was responsible and accountable, who got consulted, and who was informed during the steps of the process.

As mentioned earlier, I’ve seen organizations add the letter “S” to RACI to change it to RASCI. Including the “S” shows who should support the data governance process.

Case Study: Financial Institution Places Activity Matrix on its Intranet

A large financial institution took the use of the activity matrix to the next level by incorporating the matrix into the main page on its intranet with its data governance program. After entering the main site, visitors were asked about their level of competency and understanding around subjects related to the governance of their data.

This institution used governance activity matrices as their main proposition around filling in the gaps of knowledge for the organization. The institution provided links to the role descriptions, to the processes that were governed and to in-depth descriptions of how each role was to interact with others associated with the process that was governed.

This organization used the tools to get people involved at the right times in the processes and found the matrix to be helpful in communicating key points around data governance.

Again, there are many ways to use the activity matrix tool and its use becomes the responsibility of the people guiding the data governance program and making certain that data governance is applied consistently across the processes of the organization.

Other examples of processes where you can apply the governance activity matrix include:

• Resolving or researching data quality issues,
• Identifying and monitoring risk and compliance needs,
• Monitoring the data quality lifecycle,
• Validating and gaining approval for data governance metrics,
• Building information vocabulary templates and glossary, and
• Identifying business information needs.

Basically any process where it’s important to involve the right people at the right time.

Key Points A Data Governance Activity Matrix consists of a two dimensional chart that cross references the data of an organization with data governance activities of each of the roles and responsibilities. This matrix enables an organization to quickly see where the impact of changes to data activities will be reflected across the organization. The Data Governance Activity Matrix should include business units and specific responsibilities across business units at the top of the matrix, and the data activities, such as data migration tasks, data quality tasks, and master data tasks, already included in project activities along the left side of the matrix.