Data governance is managing data as a strategic asset for business impact… We can’t stress this point enough.
So, What Is The Role Of The Head Of Data Governance?
The HO of data governance is a strategic business and data leader who can ensure alignment between the architecture and business intelligence teams and the business. Said different, the HO of data governance is not solely a hands-on role; it has a blend of hands-on knowledge of technology and a deep understanding of data analytics but all for the aim of serving as a strategic business interface to maximize the use, access, and acquisition of data for competitive business advantage. The HO of DG is a strategic business leader and has to be able to serve as a unicorn between technology and the business, framing the business problem into data analytics and technology solutions that move the business forward. So while topics like technical metadata, the configuration of tools, file formats, and setting up the data catalog are essential, they aren’t the starting point of the DG leader.
The business usage of data should come first in terms of managing data as a strategic asset. The HO of data governance understands the use cases and how to put CDEs through lineage. The role is not only about setting up the data catalog and file formats for big data but also ensuring the correct data is a gold standard based on business needs and use cases warranting its inclusion in the catalog. It is a strategic and hands-on role but has its implementation teams to make DG a reality. The HO of data governance is responsible for uplifting the maturity levels of data management and the overall function, including the technology as an enabler.
Further, the HO of data governance is a leader that is the steward of the data management framework and ensures that data is uplifted across the lifecycle. I do not distinguish much between the data governance leader, the chief data officer, and the data management leader. These are variations on the same theme, and they are creating much confusion by separating all of these. Also, when the head of the data platform or data warehouse reports to the HO data governance/CDO/data management, it is a maturity multiplier as changes can be made to the data warehouse, and metadata can be more closely aligned between producers and consumers.
We have sub-optimized data governance by making it about the technology and thinking that architecture, engineering, or technology is the primary driving force behind treating data as a strategic asset. These essential functions should be plugged in and reported into the CDO/HO of data governance. The business side of what we govern should be given slightly more criticality than the technology. While I acknowledge that technology is essential, these folks should all hold significant roles. But to make data governance about configuration, engineering, or file formats is a sign of a struggle within the organization; that is why there is such a high turnover in the CDO role itself.
Teams Under The HO Data Governance
1. Data Lifecycle Management and Uplift: Includes the data stewards, business owner management, and the data analysts and business analysts that help uplift data.
a. Data lineage and data uplifting efforts are made here.
b. Data dictionary and cataloging efforts.
c. Business glossary for getting standard business verbiage and metrics across the organization.
2. Data Quality: This team creates quality measures and KPIs, and dashboards to provide the monitoring function and works with risk to make sure the proper controls are in place to ensure quality data.
a. The team works with data stewards, data owners, and data custodians to align the data quality measures with the business and technical requirements and considerations.
b. The team works with engineering to create self-service analytics dashboards. It runs fit-for-purpose forums to ensure data stewards know quality issues in each line of business. This team serves as a squad of people who centrally monitor quality and work with data owners and stewards to document quality issues and refer any fixes to a remediation team.
I am often asked what data quality measures are anyway, and I have a start list that I recommend all firms adopt, and they are:
- The number of CDEs that are monitored
- The % improvement in the completeness, timeliness, accuracy, validity, consistency, and uniqueness of each data element.
- The degree to which data satisfies the requirements of its intended purpose
- The structure and semantics of each data element and data set as a whole
- The % reduction in data entry and data output errors
3. Remediations/Information Management Review: This team takes any issues raised by data quality and other functions and manages the fix of any problems or errors throughout the firm. This team may:
a. Make sure errors are fixed at the source.
b. The source of the issue is identified and resolved or minimized.
c. Data that is missing is extracted properly for fit-for-purpose use.
d. Data privacy rules are enforced.
e. Data risk and controls are put into place at the source, stagging, or ETL to ensure errors or issues are addressed.
f. This team reports to data risk and compliance on how issues are being addressed and closed out.
4. Data Risk and Compliance: This is a small team of data risk and protection and legal professionals who maintain a director’s questionnaire with all the identified data risks and how these risks could potentially create problems within an overall enterprise risk framework. This team works with the HO of data governance to co-lead a data risk forum where the progress on addressing data risks is reported. Line of business (LOB) data owners and stewards also sit on this data risk committee.
5. Data Engineering (within DG): I believe this should be a defined separate team reporting into HO data governance/CDO/HO DMO. This squad or tribe or pod contains engineers who specialize in the technology to govern data. They are experts in Collibra, Informatica EDC/Axon. They also help stand up any stagging data areas or pipes to move and manage data. Again, this is a separate team from the team that manages the data warehouse or data operations. It can be the chapter lead or squad leader who manages this team. The expectation should not be that the head of the data governance organization or leader is the same person configuring Collibra or working on file formats or technical metadata. This team should be joined at the hip with the HO of DG to help implement governance and all its sub-activities, including lineage. The HO DG should know how the technology works and evaluate if it serves the team’s needs. However, getting the data in and out of the data governance tool kit is this team’s and squad leaders’ primary responsibility. This is often a missing element in organizational design and talent architectures.
6. Data Management Leader (aka Data Analytics Platform Lead): This is the role where the data analytics platform and engineering team (formerly the BI team) reports to the CDAO/ HO of DG. This allows for much more effective data governance as both analytics and DG are significant clients of the platform. This allows the learning from analytics to quickly be incorporated into DG and the platform. Your data warehouse or big data “platform” should be a living, breathing “brain.” Connecting the dots across DG and platform helps keep technical metadata up to date and creates a form of rapid cycle learning.
This is my POV on what constitutes a best practice data governance function and team. There certainly can be other variations of this, but this is what I have seen get traction. Let me know what your experience has been with data governance teams. What is the best way to define and organize DG for business impact?
I am looking forward to your thoughts.
Also, I believe some of the best teachers are on LinkedIn and YouTube. I highly recommend George Firican’s data governance course for a good POV on what I consider good data governance. His course can be found here.