Where to Govern Data – Control Points in Information Flows

My last entry suggested that data governance is not a new problem. While exploring data governance, we are revisiting the issues encountered as society built out roads, and developed modern manufacturing processes. The only difference is what we are governing this time is data content instead of a physical thing. With that in mind, it makes sense is to learn from the past and to govern at control points, or natural points of convergences.

We know that governance is needed to ensure the safe and efficient movement of anything within a system. In transportation, governance guides behavior at intersections. In manufacturing, governance guides the processes used at assembly points. In data governance, the goal then should be to ensure data that becomes integrated does so in a safe and efficient manner.  Data needs to be governed for the movement of data into integration points.

What this implies will cause application developers to balk. It would require that applications be developed while adhering to standardized and shared data practices. Without them very avoidable data integration conflicts are inevitable.

Consider two cars barreling into an intersection with no stop signs, signals, or governance of any kind. Through sheer luck many times they’ll each pass through smoothly, but inevitably they will collide. What we do to mitigate the collision risk at this convergence is to govern in advance of the situation. We decide upon rules of the road, we educate the drivers, we mark the intersection with guides, and we allow the drivers to self govern each interaction.

Data governance is like that. We decide upon the rules of interoperability, we educate the development teams, we publish our standards / guidelines and we allow the workers to self govern.  The part that is new is that those developing applications upstream applications must conform to the rule of governance while they develop. This is a fundamental change for many development teams who have been accustomed to carte blanche decision and design authority. Data governance teams may need the help of an organizational behavior specialist to mangage the shift to governed work.

The question becomes who should decide how data integrates. In the case of traffic, we use a hierarchy of federal, state, and local laws to govern behavior. For integrated and shared data, a similar governance model of enterprise, business unit, divisional, and work center rules would be applied.  General rules and policies extend from the higher levels with the most specific rules at the lower levels. Currently many organizations lack the enterprise, or business unit general rules needed for successful data governance.

The enterprise and business unit rules need to be focused on ensuring the data merges safely and efficiently into the integrated data store. It should not be the role of the team storing the integrated data to conform the incoming data to accepted standards. That responsibility belongs to the upstream data provider and should be done prior to reaching the integration point.

Let’s consider our intersection example again. The locality who governs the intersection may write laws and rules governing the intersection.  If the drivers approaching the intersection are not educated on the rules, or choose to ignore the rules then the risk of collisions rises.  This is closer to the norm of many IT organizations with regard to data governance. Those being governed are either unaware of the rules, or through lack of oversight are permitted to ignore the rules. This brings an increased element of risk to an organization.

This is also why data governance is so challenging. Getting the upstream development teams to conform, requires them to give up a certain amount of decision rights on components they have essentially owned. Getting them to conform, requires education and training on the rules of the road with regard to data standards such as master data and standardized data models.  Without some degree of conformity, it is inevitable that data conflicts will regularly occur at the integrations points in the information flow which is neither safe for the organization, nor efficient.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

 

Switch to our mobile site