The ultimate goal of all data governance programs is the same: ensuring that your data conforms to user and organizational expectations.
Such data can be
A host of information management functions and roles are in place to manage data based on those expectations as it works its way through internal systems and business processes and is used in new IT projects. Along the way, hundreds of points of risk occur: conditions that could result in one or more of the expectations not being met for one or more users of the data.
Where every point of risk exists, someone has (hopefully) made a decision about how best to manage the risk. A control has been specified and implemented according to a policy, standard, rule or guideline. The data has thus been governed. Sets of coordinated activities and controls that lead to routinely governed data comprise what the Data Governance Institute calls "little g governance."
Whether you know it or not, a "little g" data governance framework is already present in your organization; it has to be. Controls necessarily have been embedded in your systems, business processes, operating procedures, data stores and data flows. When these data controls are operating efficiently and effectively – and when their underlying objectives align with the user's objectives – "little g governance" tends to be invisible to much of the business.
Of course, sometimes a "little g governance" control point becomes visible to users. In many cases, they appreciate the fact that it is keeping them from making a data-related mistake or introducing a data error. An example is when an application control prevents users from entering text characters in a field where numbers are expected. Sometimes controls are irritatingly visible but still clearly valuable, such as requirements to enter passwords or to click "OK" as a confirmation before taking an action on data.
What a formal data governance framework is designed to address
But sometimes "little g governance" controls become irritating to the point where it's not OK with users. They can't get what they want: They don't have permission to access the data they need, or a data field that they’d prefer not to fill out is required, or the daily data they want to see has instead been aggregated into monthly totals. At that point, users of information might start to question specific controls and disagree with the policies behind them – or at least ask for the controls to be refined and better aligned with their needs. They also might ask who made the decisions that led to the controls being implemented and how they can change those decisions.
"Big G Governance" is designed to address these issues. It enables and informs "little g governance" operational data controls in the following areas:
- How business objectives and data-control objectives are aligned and prioritized.
- How the control objectives are translated into policies and standards.
- How high-level policies are then translated into more detailed data governance rules.
- Which data stakeholders' perspectives are considered during those processes.
- How “decision rights” are allocated among participants (i.e., the process for making decisions).
- How accountability is set for putting data controls into effect.
- How data-control issues and exceptions are addressed.
When organizations say that they’re implementing a data governance framework and governance processes, they usually mean that they’re formalizing the rules of engagement for addressing those "Big G" activities.
So what do data governance programs look like?
Interestingly, "little g governance" – which is dispersed across an organization's business, information management and IT operations – tends to look much the same in every organization. Invoking "little g governance" follows a typical pattern:
- A data risk is identified.
- A manager, team or subject-matter expert makes a decision on how to manage the risk, based on pre-defined empowerment levels. The decision maker is expected to specify a data control that meets the needs of stakeholders while conforming to the data architecture, standards and accepted best practices of the specific operating unit and the enterprise as a whole.
- Once a decision is made, an operational team develops, implements, manages and monitors the new control.
Ideally, these "little g governance" activities become embedded in routine data management activities. In contrast, "Big G Governance" models and processes tend to be different in every organization. Yes, they all exist to create data governance policies that can be translated into operational rules and specific data controls. Yes, they all address similar gaps in an organization's ability to crystallize data problems, activate problem-solving efforts and engage the appropriate executives in supporting data governance and setting governance policies, and then to communicate the policies to all employees and monitor and enforce compliance with them.
Designing a “Big G” data governance framework: questions to consider
But what makes every “Big G” data governance framework unique is a combination of three factors:
The problem (or problems) resulting from inadequate data governance. Is it poor data quality? A lack of access to required information? Reference data that hasn’t been standardized? Data integration challenges? Non-compliance with regulatory or data privacy requirements? Or a combination of the above?
The types of gaps or weaknesses in the existing data management and governance processes. Is there a “tone-from-the-top” gap that discourages compliance with data governance policies and rules by business units and employees? Are potential decision makers not ready, willing or able to work together? Do current management practices encourage private deals on data governance between different stakeholder groups instead of open, transparent negotiations?
The state of the existing information environment. Are data governance problems centralized or dispersed? Is the challenge in analyzing the potential impact of data governance policies, developing operational rules and definitions or enforcing compliance? How many workers will be affected in business functions, information management teams and technology groups?
The Data Governance Institute recognizes six very different focus areas for data governance programs:
- Policy, standards and strategy
- Data quality
- Data privacy, compliance and security
- Architectural integration and analysis
- Data warehousing and business intelligence
- Management alignment
Most organizations design a data governance framework that concentrates on the focus area most important to them, while also supporting other concerns. Usually, the result is a data governance program with bottom and top layers that look much like those of every other program but a middle layer that is unique to the individual organization.
That in-between layer is where things get interesting. Many activities take place there: administration, analysis, decision making, policy and expectation setting, and lots of communication. The most common organizational model is a data governance office combined with a data governance council or a roundtable of data stewards. But that basic pattern can have numerous variations. And the mix of roles, responsibilities and capabilities that an organization puts in place will ultimately make the difference between effective and ineffective translation of high-level data governance policy into operational rules and controls.
About the author: Gwen Thomas is the president and founder of the Data Governance Institute, which offers consulting and training services in the areas of data governance and data stewardship as well as a variety of information resources on those topics. As a consultant, Thomas has helped companies such as American Express, Sallie Mae, Wachovia Bank and Disney to build or upgrade their data governance and stewardship programs. She also is a frequent speaker at industry events, a regular contributor to IT and business publications, and the author of the book Alpha Males and Data Disasters: The Case for Data Governance.