By Reed Bradford
Imagine you are an executive with responsibilities for transforming your organization into a data-driven enterprise. You already know the virtues of being data-driven in the Information Economy of 2015. You have searched the internet and read the countless articles and white papers on Big Data, Data Science, Advanced Analytics, and the promises they hold. You have engaged the brightest minds, both within and outside your organization, to develop a strategy and a roadmap to realize the vision. The Reference Architecture you have adopted has everything you need to realize the end-state vision: data governance, data sources, data architecture, data stores, data integration, master data management, data quality management, metadata management, data security, data distribution, reporting, analytics, visualization, etc. You have spent many hours with your internal IT team and with technology and service providers evaluating and selecting the best technology and services to implement the vision. You have put together the required budget requests with use cases and expected ROIs and obtained the funding to move forward. You have even begun the actual implementation with hopes of seeing the business benefits materialize very soon.
Some things have gone great. You were able to quickly put in place the overall technical architecture, obtain the necessary technical experts, and data began pumping through all of the layers of the architecture… from data sources through data integration, into consolidated data stores, to data marts, and ultimately into the hands of the users in their reports and analytics.
But some things have not started perfectly. There wasn’t enough time, budget or available business resources to set up formal data governance before you got started on the implementation, and you didn’t want to put that on the critical path leading to the end-state vision, so you moved forward. Business-driven data governance will be a parallel effort that will come into the picture around Phase 3 of your roadmap. It’s enough that the business approved the project and gave you the required funding, and your team of Business Analysts will be diligent in gathering their business requirements. You plan to “knock it out of the park” and build a world-class solution to satisfy the business requirements.
Unfortunately, a number of serious problems have arisen as the implementation has picked up steam:
- It has been difficult to find people on the business side who will take ownership for business requirements for some of the key data domains and related analytics. Some of the requirements have been provided by IT managers who know the business very well, but the business has been very critical of some of those decisions. Some senior business managers insist that they were not engaged and should have been much more involved.
- The data modelers have not been able to work with the business as much as they would like and have had to make some key decisions around the data models without clear business direction. The business has not been happy with some of those decisions as they have started to see some of the reports and analytics coming out of the system.
- Your enterprise has no formal business ownership, policies, standards or processes related to data quality management, but you have implemented one of the market-leading data quality management tools. The business believes the quality of the data they are seeing in their reports and analytics is not acceptable and has questioned your implementation of a very expensive data quality management tool without the expected results.
- A number of senior business managers have started to complain to some senior business executives. The executives have begun to question the project and to start to ask many questions about how the project aligns to your organization’s business strategy, the excessive funding for a project with little ROI so far, the level of competence of the people implementing the solution, etc. You fear you will soon lose funding for what you still believe is a very promising opportunity for your company.
Does this situation sound familiar to you? As an information management and analytics professional with 30 years of experience, I can tell you it is a situation typical of what I have seen unfold over the course of my career across industries.
What is the solution? How can this be avoided? The answer: Data Governance!
Data Governance is still not well understood across both business and IT, but as you think about the purpose of Data Governance, it is one of the most important aspects of an information management and analytics endeavor and is not something that should be considered “optional” or something that should be put in place “later”.
Data Governance is the exercise of decision-making and authority for managing information assets; implemented via the organization, policies, standards, rules, processes and technologies required to ensure the quality, availability, accessibility and security of information.1
The situation above describes a small sample of what problems typically occur without the establishment and operationalization of proper Data Governance before a complex information management and analytics program is set in motion. Let’s examine each problem above through a Data Governance lens:
- Problem: It has been difficult to find people on the business side who will take ownership for business requirements for some of the key data domains and related analytics. Some of the requirements have been provided by IT managers who know the business very well, but the business has been very critical of some of those decisions. Some senior business managers insist that they were not engaged and should have been much more involved.
- Data Governance Lens: If a proper Data Governance organization had been established, there would be Business Data Owners and Stewards with clear accountability and responsibility for ensuring that the correct business requirements were gathered, approved and communicated to the BAs and to IT for each data domain and the related analytics. The business would never be in the situation of not being engaged in the program and could never come back and question the requirements… they would have provided the requirements and would have clear accountability for them.
- Problem: The data modelers have not been able to work with the business as much as they would like and have had to make some key decisions around the data models without clear business direction. The business has not been happy with some of those decisions as they have started to see some of the reports and analytics coming out of the system.
- Data Governance Lens: The Operational Data Stewards would have the required knowledge, skillsets, and responsibility to participate in data modeling workshops with the data modelers. Any questions or issues that arose during data modeling would have been escalated to the Data Owners via the Data Governance Council for resolution. Any questions or issues that the Data Governance Council could not reach a decision on would have been escalated to the Chief Data Officer and possibly to the Data Governance Executive Steering Committee for final resolution. The business would never be in a situation where they are unhappy with data modeling decisions… they would have made the decisions via the proper Data Governance process.
- Problem: Your enterprise has no formal business ownership, policies, standards or processes related to data quality management, but you have implemented one of the market-leading data quality management tools. Unfortunately, the business believes the quality of the data they are seeing in their reports and analytics is not acceptable and has questioned your implementation of a very expensive data quality management tool without the expected results.
- Data Governance Lens: The Chief Data Officer and the Data Governance Council would have established Data Quality Management policies, standards, and processes and would have been closely involved with IT in the final approval of the selection and implementation of any data quality tools. In addition, the Data Owners and Stewards would have clear accountability and responsibility for ensuring that the Data Quality Management policies, standards, and processes were followed and enforced. They would have worked closely with IT on the identification of critical data elements (CDEs), the determination of the measures of data quality important to each CDE, the establishment and implementation of data quality rules, the monitoring and capturing of data quality exceptions, the reporting and trending of data quality measures on dashboards and scorecards and the remediation of data quality exceptions and issues. The business could not complain about the quality of the data in their reports and analytics… they would be accountable and responsible for the quality of that data.
- Problem: A number of senior business managers have started to complain to some senior business executives. The executives have begun to question the project and to start to ask many questions about how the project aligns to your organization’s business strategy, the excessive funding for a project with little ROI so far, the level of competence of the people implementing the solution, etc. You fear you will soon lose funding for what you still believe is a very promising opportunity for your company.
- Data Governance Lens: One of the responsibilities of the Chief Data Officer (CDO) is to ensure that the Data Strategy and Data Governance align to the overall Business Strategy. The CDO would have worked closely with the CIO, CTO, Business Unit Executives and the CEO to ensure all information management and analytics projects aligned to the Business Strategy and there would be no question as to how this project aligned. Funding would be clearly understood and approved and the CDO would provide ongoing updates and communication about the project to ensure continued alignment and business support. Proper governance of the project by the CDO and his Data Governance organization would ensure that no questions arose as to the competence of the people implementing the project. There would be clear traceability from designs and implementations to business requirements and governance ownership. Operational Data Stewards would provide the required ongoing operational support to ensure the quality, availability, accessibility, and security of the required data, reports and analytics.
As you can see, proper Data Governance would have solved all of these problems and kept the program successfully moving forward.
However, there are cases in which Data Governance was put in place before a major information management and analytics program, yet many of these same problems and others still occurred. What then? The answer lies in ensuring that guiding principles and best practices are followed in the implementation of Data Governance:
- PARTICIPATION: Every Data Governance role must have proper criteria for participation and the right people must be carefully selected for each role. For example, leadership and decision-making skills and a detailed understanding of the business are critical to a Data Owner role. Putting the wrong people in Data Governance roles will lead to failure.
- EDUCATION and TRAINING: Data Governance requires education and training across the organization to provide Data Owners, Stewards, and other roles with the right knowledge and skills.
- SIMPLICITY and USABILITY: A Data Governance model that is simple and usable is critical to success. All Data Governance processes must have a simple, clearly defined process flow and a RACI chart for ease of understanding and operation.
- PRIORITIES: Do not attempt to roll out an entire Data Governance program all at once. Start small and focus on high-impact priorities. For example, if there are some known Data Quality issues plaguing your information management and analytics program, then start with a Data Quality Management program for Critical Data Elements.
- STRATEGIC-ALIGNMENT: Utilize the business strategy to guide the prioritization of data policies and critical data issues, as well as, the direction for the program.
- LEADERSHIP: Champion the “right” data policies, guiding standards, operating procedures, and governed solutions to increase the value of critical data assets.
- FLEXIBILITY: Recognize that “one size does not fit all” when it comes to Data Governance. Encourage creative and innovative approaches to remediate data challenges.
- COMMUNICATION: Frequent, directed communication will help reduce anxiety and provide a mechanism for gauging when to “course correct”. Clearly describe, outline the rationale for, and effectively communicate all decisions and directives.
- COLLABORATION: Embolden cooperation and partnering (e.g. cross-organizational, cross-business unit, cross-site, and cross-geographic region) on enterprise-wide mandates, integration, and data consolidation.
- ENFORCEMENT: Data Governance policies, standards, rules and processes must be properly enforced. The CDO and the Data Governance Council must be given the proper authority for enforcement actions.
Following these guidelines and best practices will lead to a successful Data Governance program.
The hope is that the next time you are involved in a major information management and analytics program you will recognize the importance of establishing Data Governance and work with all stakeholders to put this important function in place prior to embarking on the program. Information management and analytics programs are very important to the success of any business with the potential for excellent ROI, and yet they are often quite costly and carry a very real risk of failure without proper Data Governance.