Understandably a lot of tool vendors want their toolset applied to an organization’s data governance initiatives regardless of policy and procedures that businesses need to follow. The issue here is that policy and procedures vary across industries and lines of businesses. In the case of a pharmaceutical company, policies may be dictated by regulatory authorities or the geography in which the product is being made. In manufacturing, the policy may be controlled by cost, sensitivity to market demand and suppliers.
The point is, any tool can take on a job and do as it’s told to do – but who sets the policy and strategic planning to instruct those tools? Data governance is a journey, which not only requires tools, but also an intuitive master plan that incorporates process, objectives and measurable results. It follows a path that should be guided by best practices. Solutions developed and lessons learned should be reusable and applied to reduce rework and maintain consistency in future projects. Because data governance is data-intensive, attention should be paid to assessing which data is or is not valuable to the business. This can be defined as “field value” versus “context value.”
Let’s look at a specific example of this. A data steward was instructed to find and remediate all conditions where field values were entered as placeholders. A placeholder could be a sample name such as “John Doe” or an address such as “123 Unknown St.” The problem here is that the field value was satisfied, but the application or tool assisting with data governance doesn’t see this as an error, since the name and address were acceptable from a field requirement perspective. So how do you find these anomalies?
A data governance tool that does not take policy and business requirements into account will not be able to find and return these records for correction – unless of course the data steward already knew all the various terms used by hundreds of business users in their company, which is highly unlikely. A data governance solution that includes an automated way to address business requirements across the data will see this field and assess it for its context within the broader use and application of the information. If the field does not conform to the “business value” of the expected information, it will be rejected and captured for remediation, saving countless hours of research for the data steward! Also, going through this process, new rules can be automatically built and reused later for similar conditions or requirements, saving developers hundreds of hours writing rules independently.
Software automation is a great thing, but it’s invaluable when it can collapse the time and effort required to achieve business goals or the outcomes desired by the business, which are not necessarily the same objectives of the tool suppliers and their software. Goetz’s advice to evaluate data governance solutions based on “… strategy, process, and administrative aspects of governance, not just data management and data processing…” is no longer a nice-to-have, but a have-to-have in competitive business today.