Data Governance – The Missing Link between Data and Process?
Posted by 
Share this Post
Is data governance the missing link? Marty Moseley ponders.
In the comments on a recent blog by my friend Rob Karel, another respected blogger stated that there was a missing link between data and business process, which is data governance. I agree that the influence of data governance is missing, but respectfully disagree that there is a missing link.
Maybe I'm just being picky with regard to semantics, but I think the link is there in multiple kinds of modeling and specification languages. We have been using visual and other languages for decades that specify what structural and semantic levels of quality a set of data must adhere to, to be useful to processes (DFDs, IDEF0/1X, IEF, IEW, UML...).
The problem is not that there is a missing link. For a few processes that manage highly shared data, the designers of the processes which consume, use, propagate, augment, link/unlink, update and delete data are not aware of, nor do they conform to, policies that will guarantee the highest levels of quality for the data they operate upon.
In other words, we've taken the "fit for purpose" designation to such a finely-focused (read: myopic) level that data are only of concern to meeting the specific needs of a specific process for a specific business purpose for which the process is being defined/configured/tuned/implemented.
Said another way, the requirements that drive the specification of a process' use of data are lacking!
They are missing the influence of a set of declarations of policy (see Jim Harris' latest post and an earlier one by me - Hear Ye! Hear Ye!) established by a data governance board, which specify what must be done in order to protect and advance the quality of the data under its purview.
These declarations of policy are the biggest opportunities that data governance initiatives have to influence how data are managed - especially those data which are highly shared, highly critical and highly sensitive (in other words, master data).
This goes way beyond populating a data dictionary, or profiling a set of data (see Evan Levy's post on The Flaw of the Data Inventory), or managing other metadata for a DQM project. It goes beyond the process models for a set of business functions and which data they create, read, update and delete (CRUD).
This looks at the problem from a data perspective, instead of a process perspective. A process-oriented view says, here I am, a process that's a child of some other process, a parent (potentially) to a set of processes, with interfaces to still another set of processes, data stores and/or users.
In my view of reality, I need to exchange a bunch of data in order to fulfill my contracts with other processes with whom I work (contract-based integration is another fun topic). It looks at the world thru what it consumes and produces.
With the "fit for purpose" rule applied, as long as I get the data I need to perform my tasks, and as long as I can produce the data needed by my clients, I'm good to go. The last thing in the world I want to do is to schlep a bunch of data around that serve no purpose for me.
The data-centric view says something altogether different. In the MDM world, it says, I'm a set of data that seems to be used all over the place (by all sorts of business processes, in a bunch of systems, on a bunch of screens and reports etc.). I seem to be CRUDed in many different systems, and there's no real agreement on what I mean, how I'm structured, how I'm populated and how I'm used.
Would I say that I am an asset or just a data resource to be used by a given process? If I am an asset, how well (or how poorly) am I "treated?"
This is where data governance steps in and ensures that declarations of principles, policies, procedures/processes, business rules and metrics are defined in order to get the most value out of your most critical data assets.
If you expect a process designer to understand the nature of the data they CRUD, and to get all the corner cases right, you are going to be disappointed. Not that there's a gap per se, but that there's a missing specification: the policy that defines how critical data must be treated for the benefits of an enterprise.
5 Responses »
Trackbacks
- Tweets that mention Data Governance – The Missing Link between Data and Process? | Mastering Data Management -- Topsy.com
- Trust and Verify: How Data Quality Can Foster IT-Business Alignment | Mastering Data Management
Leave a Response
Entries(RSS)
Great post, Marty!
Yes, a set of declarations of policy, provided by data governance, which establishes the Missing-only-because-no-one-is-aware-of-it-or-chooses-to-ignore-it Link connecting not just data and process (business or technical), but also people and technology as well.
Whether you begin by looking at the problem from a data perspective or a process perspective, is perhaps, well, a matter of perspective.
However, I think that no matter from which one you start, you need to look at all applicable perspectives, in my opinion, in order to understand the complete context of the data governance policy that must be defined, documented, communicated, measured, and enforced.
As to whether or not data governance is truly the missing link, as you said, maybe it's all semantics, but I think it is. Except, I don't think it's the missing link between data and process--I think it's the missing link between successful and unsuccessful enterprise information management--and I am not just talking about master data management.
I think it's time we all said:
“Data Governance, You are the Missing Link, Hello!”
Best Regards,
Jim
P.S. Thanks for mentioning my blog post for you know who
Marty,
Thanks for referring me a "respected blogger." I'm very new to blogging. I feel really honored since this comes from a truly respected blogger.
I don't disagree that business process owners, when left to their devices, would take a myopic view of data. When you have a bunch of processes each its own myopic view, that's how we got into this mess in the first place, and why the problem is so hard to solve. But solve it we must -- it's a business imperative -- and we need to get to the root of the problem.
If we accept that business processes produce data (not IT systems), then it follows that we have to have policies in place so that business processes are accountable for data output to benefit the entire enterprise. The enterprise view of data, however, is based on the collated and rationalized needs of the downstream business processes that consume the data. So the trick is to codify these collective needs as policies, enforce the policies. This is data governance, no?
Modeling languages can document the mechanics of how physical data flows, but they cannot declare or enforce policies for data. (Perhaps I should say, Data with the big D.)
The problem with the data-centric approach is that it's a solution looking for a business problem to solve. So why not start with the problem, which is how business processes produce and mess with data?
My blog on data governance as the missing link is here.
With respect,
Winston.
Winston -
Right on, right on, right ON!
Yes - the specification of these policies IS the essence of data governance! And your "chicken or egg" question about the data-centric approach leading to a solution in search of a problem is also right on as well.
Anyway, that's why my Agile DG process starts w/ defining the "burning bush" business process issues FIRST (shameless plug - sorry).
Have a stellar weekend!