What is decentralized data governance?
Decentralized data governance refers to a system of managing data in which decision-making power is distributed among a network of participants rather than being centralized in a single authority or organization. In a decentralized data governance model, data is shared and managed among a network of nodes, with each node having the ability to contribute to the governance process.
Traditional Data Governance
In my discussions with CIOs analyzing data over the last several years, they have repeatedly told me they strongly dislike traditional data governance. And asked at times, could they just be data custodians. When I asked why, each time they said they either had a data governance strategy forced top-down on their organization’s data side, and everyone disliked them for doing it; or, IT took on data governance themselves.
Therefore, it is not surprising to learn many executives have come to “perceive their own data and data governance processes as to be bureaucratic, complex, expensive, and largely discretionary.” (Data Governance for Dummies, page 7).
Yet failing to build and implement an effective data ownership model is harmful because it remains a fundamental DataOps process. Without question, data governance that is top-down or overly centralized has failed organizations that implemented it. For this reason, many authors have suggested a non-invasive approach—thank you Bob Seiner for leading this charge. These approaches are less centralized but allow organizations to federate their governance efforts. For example, Mukul Sood, Chief Architect at Slalom, says “the federated data governance model, distributes a team of data governance resources among the business functional teams, and a centralized data governance leader is accountable for the overall data governance program. This model is recommended to enable lean and nimble data governance without unnecessary hierarchy data silos and tiers.”
A decentralized plus federated governance framework makes sense for a number of data governance missions. For example, data governance for data quality could start with just one side managing data per domain. However, even here there is a point at which, for example, financial teams need to move their own datasets into other systems managed by other groups. So, it can make sense to start small with a domain team and then clone this into multiple teams in a federated model. The fact is we live in a connected world of applications and domains. It is hard to say just one team should be involved.
Centralized vs Decentralized Systems
When comparing centralized vs decentralized IT pros and cons, one thing was clear. Without question, centralized data governance ended up being implemented in a command-and-control fashion. In some cases, it created a centralizing team that owned data. These people often became effectively a tax for the organizations for which they managed data governance.
Its leaders controlled master data, including the data stewards that managed data creation and data access control. This put in place a central body with authority, responsibility, and control over data access. Often, this method tended to focus more on data controls and limitations. This kind of tight control over the ownership of data was more focused on restricting data use versus enabling self service use and discovery.
The problem with this view is it runs counter to the research of Raffaella Sadun of the Harvard Business School, Philippe Aghion of the Collège de France, Nicholas Bloom and Brian Lucking of Stanford, and John Van Reenen of MIT, which showed “a company’s performance during and after a recession depends not just on the decisions it makes but also on who makes them. In particular, this research found that decentralized firms may be better positioned to keep business growth and weather macro shocks because the value of local information increases.”
The above research effectively makes the business case for self-serving most elements of data management, data control, and utilization. An appropriately managed decentralized data governance framework, says Data Leadership Collaborative’s Advisory Board Member Mark Palmer, means “each citizen plays their part to implement decentralized data governance, and the federation swings into action to add engineering, governance, and compliance built around this effective workflow and culture.” Without question, a decentralized data governance model is a newer approach to data governance. It is supported by new concepts, including data mesh. In this approach, data producers and domain experts are empowered to manage and monitor data flows and access points on their own.
Federated Data Governance
Federated governance argues for centralized standards, policies, and governance, but only centralized governance aimed at allowing for de-duplication of effort and preventing similar issues across business groups. It recognizes that decentralized approaches are problematic for some areas of governance. For this reason, it is critical that organizations be clear from the start about their objectives for data governance.
According to The Data Governance Institute, there are six different focus areas for data governance, strategy, and integration, including:
- Policy, standards, and strategy
- Data quality
- Privacy, compliance, and security
- Architecture and integration
- Data warehousing and business intelligence
- Management support
I would argue data quality, data warehousing, data discovery, data warehouses, analytics, and key elements of business intelligence can clearly be implemented in decentralized form. Especially if the data involved is not a data product, but primarily focused on a single business unit or function. However, the other types of data governance will require federated data governance from the start.
Data Security Governance
Depending on the corporate operating model, one of the areas that screams out for centralization is privacy, compliance, and security. This is what we refer to as data security governance. How this is implemented matters. This is because most enterprise data flows between corporate systems.
And while one could clearly start the process by governing data assets across domains, this process is problematic when it encompasses an enterprise architecture perspective. What happens, for example, when customer data flows between Salesforce automation to customer support and financial systems? Clearly, the rules of the road for data assets need to operate consistently across different functional areas. Add to this compliance, which needs to be consistently managed across enterprise systems. There are clear penalties for doing it any other way.
However, there is good news. In the past, much of the difficulty concerning centralization and poor data quality was due to the need to manually manage data access system by system. Fortunately for business leaders, new technologies make it possible to simultaneously discover risky data and implement a single policy and control for managing that data across the data estate—without coding. There is no penalty for centralization of data captured for privacy, compliance, or data security governance. This type of data governance is a lever of probability. Good governance reduces the probability of risk. It doesn’t eliminate it, but it goes a long way in mitigating. Bad data governance policy or no governance is a formula for high risk.
Without question, data governance solutions need to be more collaborative and culturally nuanced. Top-down and forced data governance failed the organizations that tried to implement it. In fact, analysts have found these approaches tend to fail. It makes sense to decentralize data availability and federate data consistency. However, for data security governance, it makes sense to centralize for compliance and federate across the organization from the start.Have questions about the centralized vs decentralized IT pros and cons of data security governance? Need to know what’s best for your unique cloud operations, business rules, and other data management capabilities? Contact us today.