Everybody involved in the data space is familiar with data governance. It is a topic that is widely written and discussed, but we rarely come across organizations where it is implemented effectively and sustained for any significant time.
For a successful data governance implementation, it has to be ‘just right’. It is a matter of getting the correct balance between governance and agility to deliver on business commitments.
Heavy governance equals bureaucracy. In such cases, the business users come up with creative ways to circumvent the process or bypass IT altogether – creating ‘Shadow IT’ – which is not an efficient use of an organization’s resources – people and money.
Make governance too light and the results are no different. Each functional team builds their own siloed solutions creating inefficiencies and severely limits an organization’s ability to scale and operate as a connected enterprise.
This article touches a couple of fundamental aspects of data governance that we need to think about before we jump into the framework, standards, people, process, and technology.
Type of Governance
Whenever anybody mentions governance, what immediately comes to our mind? Bureaucracy – Policing – Gate-keeper – Workflows/approvals – Delays – Unnecessary meetings – Auditing – Controls?
Why does our business community feel apprehensive when they hear about data governance? Do they feel this is one more process for IT to apply more controls?
In the new world of Agile and DevOps, how does data governance fit in?
With all these open questions and concerns hovering around us, how should we think of operationalizing data governance?
Like with any other business concept, there is no one single answer that will work for all scenarios. Having said that, we could incorporate the below two approaches to data governance:
‘Gate-keeper’ Governance = before implementation
‘Auditor’ Governance = after implementation
This type of governance is required when we have standards that need to checked and verified before implementation or deployment. These standards would include:
· Regulatory, compliance and security standards which are not negotiable.
· Components that have an enterprise-wide impact
· Design and architecture that cannot be easily changed once implemented
This governance process obviously adds cycle time. These reviews are usually perceived as bureaucratic by the business users. Hence it is critical that we minimize the number of standards which would fall under this purview, keep the process simple with quick turnaround time and ensure that the requestors are continuously kept updated on the progress.
This type of governance makes sense when non-adherence to the standards does not severely cause impairment to the organization. The standards can be checked after implementations. And, the implemented solution can be easily re-designed and/or rebuilt to meet the standards.
Standards or Best Practices
In the context of government, we need a set of rules or laws that are used as a basis to govern. But does each and everything we do need laws? For example, while economic well-being of a country is critical, there are no laws on what percentage of income individual citizens should save for retirement. But there are surely many recommendations out there on retirement financial planning.
Similarly, within the scope of data governance, we need to differentiate between standards (laws) and best practices (recommendations).
Standard could be defined as any rule, principle or measure established by authority. In our context of data governance, these are standards that are non-negotiable, which everyone must follow.
On the other hand, best practices are recommendations. The product team is at liberty to decide if, and which, best practices to incorporate into their solutions.
Governance for Analytics
So, how does what we have explained above apply in the case of analytics? How do we balance all these conflicting priorities?
An analytics solution has two main components – analytics data and analytics consumption.
This is the data repository where the sources of truth are published. Our intention is to ensure that all downstream consumptions use these sources of truth. Hence the data architecture should follow all the standards to make it a robust data model to support multiple use cases across the organization.
Since this has enterprise-wide impact, we need to ensure that any changes to the data model are reviewed and verified before implementation – ‘Gate-keeper Governance’
We are increasingly enabling our business users to build their own analytics – driving self-service. Our users, spread across the globe, should be able to quickly create dashboards in response to the ever-changing demands of the business. To facilitate this, we should allow the business users to build their dashboards – like they would be using Excel or PowerPoint. The users are the best people who really understand the data and are in the best position to make the best use of the data. To make them self-sufficient, we should document and publish best practices on building dashboards which are easy to follow.
The governance team can periodically review what the users have built and help them remediate if necessary – ‘Auditor Governance’. The users don’t have to involve IT and they don’t have to go through the bureaucracy of data governance. These ‘auditor governance’ reviews could help the IT team plan targeted training and ‘how-to’ sessions to share best practices.
With this background, we will discuss how to define a data governance framework in a future article.
Disclaimer: The opinions expressed in this article are the author’s own and should not be attributed to the author’s employer.