I have been spending time recently working with a lot of my customers on Data Governance and the impact it has on the culture of the enterprise. What I have seen as a recurring challenge in this area has been a fundamental understanding of Data Governance; an understanding that is based on a structural as well as a functional level of knowledge about Data Governance. With the advent of the “Big Data” phenomenon, Data Governance has become even more important to the success and well being of almost any business, and yet, more often than not, most businesses struggle to achieve even the most basic functional levels of Data Governance. Take a look at the list below and walk through the issues that I raise. Be brutally honest with yourself and see how many of these are issues that you are facing, and / or will face when you get serious about Data Governance.
Mistake 1: Failing to define data governance
The conceptual idea of data governance has become a veritable dumping ground for all things data. Google the term and you will come up with references to data quality, metadata, data warehousing, data ownership, and data security, to name just a few. I would define data governance as the organizing framework for aligning strategy, defining objectives, and establishing policies for enterprise information. What is really important is how you define data governance and how your organization understands it. As promising as the potential of data governance is, it has failed to be realized in many companies because people misinterpreted its meaning, its value, and what shape it would eventually take.
The most common mistake companies make is using “data governance” synonymously with “data management.” Data governance is the decision-rights and policy-making for corporate data, while data management is the tactical execution of those policies. Both require executive commitment, and both require investment, but data governance is business-driven by definition, while data management is a diverse and skills-rich IT function that ideally reports to the CIO.
Once data governance becomes a dirty word, an organization rarely gets a second chance. Attempts at euphemistic substitutes do not hide the fact that definitional clarity and a firm vision for data governance do matter.
“Ready, shoot, aim”: failing to design data governance
As with any strategic initiative that enlists both business and IT and is process-centric and highly visible, data governance must be designed. Designing data governance means tailoring it to your company’s specific culture, organizational structure, incumbent ownership environment, and current decision-making processes. It means articulating the value proposition for cross-functional and formal decisions about corporate information—whether by minimizing compliance exposure or security breaches, over- or under-communicating to customers, consolidating product catalogs, or supporting dozens of other potential business drivers. No two companies treat these issues in exactly the same way, and data governance is never exactly the same across companies.
Consider the following examples. A multinational financial services firm that is structured hierarchically and is managed with a very “formal” approach from a culture standpoint. Decision making is top-down. Budget sign-off goes high up in the organization for relatively small expenses. Executives are big on community driven meetings and roundtable discussions. Consensus reigns.
A technology firm where everyone is tech-savvy. People come to work when they are ready to work and work until they have accomplished what needs to be done. There are no formal schedules to be adhered to, and everyone solves their own problems, and helps others solve theirs if needed. These guys fix their own problems and make their own decisions. Anarchy is the rule.
Data governance looks very different at these two companies. At the financial services firm, three different governing bodies are involved in the data governance process, each with its own checks and balances. The technology company relies on established yet grassroots effort. The stewards use an online knowledge base to submit decisions for review, subject to occasional tie-breaking by executives. These stewardship units are endorsed by divisional managers, who want to see measurements for data quality, integration, and deployment velocity improve.
In both cases, deliberate data governance design ensured that governance supports the company’s culture, organizational structure, implicit hierarchies, and way of doing business, while making sure its value is well understood and ultimately measurable.
Treating data governance as a project
In a well-intended effort to fix what’s broken, many companies will announce a data governance plan with much fanfare. An executive might assemble a cross-functional team, extracting its members from existing projects, creating an ad-hoc data governance SWAT team. Others will hang up the Center of Excellence shingle and treat data governance as an isolated organization of data-savvy individuals. Still others will inaugurate a data quality task force and call it data governance. In each example, data governance is formed as a discrete effort, when in fact it should be “baked in” to existing development and decision-making processes.
When an initiative is defined as a project, it is, by definition, finite. The reality of data governance is that it should be continuous and systemic. As information needs change, data volumes increase, and new data enters the organization via new systems or third parties, decisions about how to treat, access, clean, and enforce rules about data will not only continue, but they will likely also proliferate. A structured, formal, and permanent process for making these policies and decisions should be retrofitted into the way a company develops its data and conducts its business.
Ignoring existing steering committees
A key indicator of data governance success is an environment that encourages decision-making bodies. Call them councils, steering committees, management roundtables, or advisory teams. These bodies are usually composed of individuals from across business functions who have both the authority to make decisions and the accountability to ensure that those decisions are enacted and ultimately drive business improvements.
In instances in which the company has already institutionalized steering committees, it would be foolish not to leverage their knowledge and clout. By inviting incumbent decision-making bodies to participate in the data governance process, you effectively institutionalize data governance as a component of corporate policy making. You also implicitly enlist the support of a variety of individuals, and change occurs one person at a time.
Overlooking cultural considerations
Changing entrenched organizational paradigms and behaviors is perhaps the biggest obstacle for any governance effort. Examples include a corporate culture that stresses consensus over clear accountability, the absence of decision-making protocols, individuals unaccustomed to making decisions, or poor communication and planning. Common organizational constraints can derail governance before it begins.
Regardless of your organization’s explicit structure and biases, establishing unambiguous decision rights is a requirement for governance to thrive. Existing cultural norms should inform, but not necessarily dictate, how decision rights and accountability are assigned. Effective governance often challenges intrinsic ideas about what decision making means. Therefore, the governance program must also clearly articulate its mission and value, develop communication plans, and plan for, champion, and reward change—often one business constituent or person at a time.
Remember: one size does not fit all. The design of your governance framework must address the unique challenges and biases in your organization.
Prematurely pitching data governance
In today’s environment, executives and staff alike are wary of the sweeping reforms and lofty benefits typically promised by enterprise programs. As a result, even the most crucial enterprise data governance effort can start with one mark against it. Soliciting C-level executive sponsorship, broadly evangelizing expected outcomes, or establishing working teams without a clearly defined vision or framework to achieve the intended solution are all fraught with risk.
In the first phase of its data governance program, a multinational manufacturing company solicited several business and IT subject-matter experts to function as data stewards. The stewards were tasked with identifying high-impact data issues within their domains that governance would rectify. The stewards did an excellent job. The problem: there was no defined procedure to validate, prioritize, or resolve the ever-increasing flood of identified business problems whose root causes could be attributed to data issues.
In this all-too-common example, a team was assembled and significant effort expended to expose some particularly painful data sores without a method to heal them. A majority of the issues uncovered were good candidates for governance, but the lack of appropriate expectation-setting prior to the exercise led to frustration and mistrust. Data governance became the proverbial dirty word, and getting business owners back to the table to talk about how to implement governance and close the loop remained an uphill battle.
Expecting too much from a sponsor
Executive support and management sponsorship for data governance are critical. A motivated sponsor, with a clear vision and the ability to communicate it to both senior executives and those he manages, is an important contributor to governance success. That being said, there is a limit to what even a great sponsor can be expected to do.
Consider this scenario: A company initiates data governance after a strategic business intelligence program fails to deliver expected results due to various data issues. At the CEO’s behest, key business stakeholders from each region are elected to a data governance steering committee. At the initial meeting, the CEO describes his vision for data governance, outlines some expected outcomes, and bids the group adieu. His expectation? That the stakeholders will move the ball forward and define a plan for execution.
Sponsors, particularly those at the executive level, believe that value lies in their support, not their participation. They are, therefore, best leveraged to communicate the vision and objectives of data governance to their respective organizations. When it comes to sanctioning and evangelizing the program or rallying the troops, nothing beats an effective and engaged sponsor. Just do not expect them to do the heavy lifting involved in data governance design.
Sponsorship for the data governance program will change over time to reflect current business priorities and needs. The framework and process under which governance executes should not.
Relying on the big bang
The mantra think globally, act locally is particularly apt when embarking upon data governance. The issues addressed by data governance are far-flung and pervasive, ranging from arbitration of cross-functional data usage to information privacy, security, and access policies. As a result, governance initiatives attempting to address an array of enterprise needs in one big bang are quickly squelched by role confusion, prioritization debates, “emergency” development projects, and a general backlash of the incumbent culture. Add the inevitable kinks to be worked out in any new process, regardless of how considered the design, and failure inevitably follows.
To avoid these risks, successful programs begin with a series of tightly scoped initiatives with clearly articulated business value and sponsorship. As the old saying goes, “Rome wasn’t built in a day”. Neither is a mature enterprise data governance program. While an incremental approach takes time, not to mention patience, it engenders business support by demonstrating the value of governance in a context relevant to each stakeholder or sponsor. Most important, a phased approach establishes data governance as a repeatable, core business practice rather than a standalone “once and done” project.
Being ill-equipped to execute
Most companies do a good job of implementing governance policies within the scope of an initial business process or application release. However, the need for ongoing maintenance and auditing is frequently overlooked or underestimated. Because data is constantly being generated, new applications are added, business processes change, and users come and go, data management becomes a full-time endeavor. Anyone who has been involved in a massive, one-time data clean-up or conversion project, only to have “dirty” data reappear over time, understands this all too well. Vigilance is required to monitor compliance with existing standards, enforce new behaviors, and ensure that old habits do not creep back into common usage.
I would define data management as the tactical, day-to-day execution of data governance policies. For example, a typical data governance policy may mandate that sensitive customer data be stored in secure formats and available only to authorized users. Implementation of an appropriate storage algorithm and ongoing maintenance of user permissions are data management functions typically handled by resources in IT, security, or by a formally designated data management group. Such a group should be equipped to tackle these issues as the business continues to evolve.
Data governance and data management are symbiotic by nature. The most relevant or vital data governance policy is of little merit just sitting on a desk. To be perceived as valuable, data governance must be measured, ultimately demonstrating positive outcomes and hard payback. To do that, you must be able to manage data in a structured and tactical way.
- Rockin’ the CASB – What you need to know about Cloud Access Security Brokers …
- Cloud Tweaks Blog … What Do You Know About Cloud Security?
- Security Awareness @ ISC2 Security Congress 2015
- Secure the Power of the Cloud … (and get certified while doing it)
- Announcing Exchange Server 2016 Preview!
- VMware Scripting Overview – A quick look under the hood
- Checklist: Use AD FS to implement and manage single sign-on with Server 2012/R2
- Checklist: Setting up a Federation Server (ADFS) for use with Office 365 on Windows Server 2008/R2
- The (ISC)² CISSP Domain Refresh … Are you prepared?
- vSphere 6.0 is on the way !!! …. Are you ready???