Data Governance Should be Formalized as a Business Process

We at Kalido frequently describe data governance as the business process of managing data assets. Data governance processes are day-to-day activities no different than other end-to-end business processes like order-to-cash and procure-to-pay. Data policies are the instruments of data governance; therefore, activities of data governance should be based on the lifecycle of data policies. We can divide these activities into three sequential steps: policy definition, policy implementation and policy enforcement.

Policy Definition

Many data policies are, in effect, service level agreements (SLA) between multiple parties, including data providers and data consumers. In the billing address example I discussed in my last blog, Order Entry process is one of the “Providers” of data, and Invoicing is the “Consumer” of data. The agreement holds the Providers accountable to a certain standard. The Consumer defines a set of needs linked to expressed business benefits, and the Providers agree to meet these needs. If there are multiple providers, such as a third party or Customer Service who may also enter customer billing addresses, then all providers need to sign up to the SLA. The process of creating and changing policies involves multiple steps and multiple stakeholders. Policies may need approval by the Data Governance Council. A crude analogy is that Policy Definition is similar to the legislative process of making laws.

Policy Implementation

After a policy is defined and approved, the next step is implementation. Individuals affected need to be notified of the new policy. The audience is often much broader than the key stakeholders involved in policy definition. This is particularly true for policies that deal with human behavior. In the billing address example, we would notify all the order entry clerks, and sales representatives, and any other parties that can create and modify customer data and order data. They need to know that they’re accountable for ensuring the correct billing address is entered into the system. The policy covers outsourced business processes and third-party data providers and holds them accountable for the data they produce.

In addition to notifying the business side, a policy may call for changes to IT systems. An executive at a healthcare insurance company once explained to me a data governance problem he faced. His company receives the entire US Postal Service (USPS) address file. For free. USPS also issues a postal “Change of Address” file on a regular basis. Companies that receive data from USPS are required to apply the change of address files in a timely manner to all the databases where customer addresses are stored. This requirement can be defined as a policy for the benefit of regulatory compliance. The owners of all systems that store customer addresses need to be notified of the policy, and they need to commit to making the required changes within a certain timeframe.

Policy Enforcement

Once a policy is implemented, it needs enforcement. How would we enforce our example policy for customer billing address? One way is to put in place an automated monitoring mechanism. For example, we can put a process in place on the database that Invoicing uses to look at whether each order to be invoiced indeed has a valid billing address. This monitoring process needs to be executed regularly – daily or weekly – to report violations. Depending on severity, violation could trigger remediation steps, which should also be treated as a business process involving data stewards, business process owners and IT.

Finally, the compliance data generated by the monitoring process needs to be collected, compiled and reported on. These metrics provide the entire organization information on the overall state of data assets, highlighting their trustworthiness. We can see if improvements are being made. And, we can use these metrics to hold the parties that have agreed to policies accountable.

In my next blog, I’ll write about how to organize for data governance.


This blog is part 5 of a multi-part series of blogs on the topic of Enterprise Data Governance. To read other posts from this series, please see below.

Part 1: What’s the Root Cause of Bad Data?

Part 2: Traditional Approach to Data Management Only Treats the Symptoms

Part 3: What do Environmental Policy and Data Governance Have in Common?

Part 4: Data Policies are the Instruments of Data Governance

Part 6: Send in the Yellow Jerseys: Organizing for Data Governance

Part 7: How to Set the Right Initial Scope for Data Governance?

Part 8: How to Build a Business Case for Data Governance?

9 replies
  1. Sachin Sinha
    Sachin Sinha says:

    Thought provoking piece on Data Governance. Indeed it would go a long way if we start thinking of data governance processes as business processes rather than an IT task. We would have better success rate in coming to an agreement on setting SLAs and enforcement of policies if these are viewed as business processes.

    looking forward to your next post in this series

  2. John Owens
    John Owens says:

    Hi Winston

    I agree with what you say with regard to Policy Definition. However, I disagree on implementation and enforcement.

    The only way to successfully achieve quality, and data quality is no exception, is to make it an integrated part of the appropriate business functions of the enterprise.

    All quality comes from the business functions (core activities) of an enterprise – quality of product, quality of data, quality of customer and employe experience.

    It is perhaps indicative of the immaturity of the data quality industry (sadly it has become an industry) that it perceives data quality as something separate to the core business of the enterprise.

    Some even advocate that data governance should be a “business process” in its own right. This is about as bizarre as advocating that “keeping the patient alive” should be a “process” over and above treating the patient.

    All data in an enterprise is either created or transformed by a business function. Consequently, all data quality issues are a direct result of a flaw in the execution of a business function. The only way effectively resolve the cause of the data error and prevent further occurrences is to resolve the flaw in the business function.

    Any other approach creates a totally disjointed set on activities in the enterprise termed “data quality” or something similar that are, although they consume a lot of time and energy, doomed to failure.

    So yes, define your data quality policy (these would be better termed ‘business rules’) but then make them an integrated part of the appropriate business functions.


    • Winston Chen
      Winston Chen says:

      John, thanks for your comment.
      I agree with your view that quality needs to be integrated into business processes. In fact, data quality policy is an SLA between business processes that need certain data, and the business processes that produce them. That is how data quality policies are implemented. But that doesn’t obviate the need for a set of over-arching process that orchestrate this: understanding who’s accountable for implementation, and monitoring the outcome, etc.. In manufacturing, companies have horizontal quality business processes that intersect with individual processes along the supply chain.
      I don’t think instituting data governance as a business process is bizzare at all. Quite the opposite, the process-oriented discipline is exactly what we need in the entire field of data management. We need to move away from project/initiative oriented approach to everything.
      Thanks again for your thoughts.

Trackbacks & Pingbacks

  1. […] Part 5: Data Governance Should be Formalized as a Business Process […]

  2. […] and enforcing data policies. Pretty simple, isn’t it? (See my blog on data policy and data governance processes. […]

  3. […] Part 5: Data Governance Should be Formalized as a Business Process […]

  4. […] Part 5: Data Governance Should be Formalized as a Business Process […]

  5. […] Part 5: Data Governance Should be Formalized as a Business Process […]

  6. […] Part 5: Data Governance Should be Formalized as a Business Process […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply