Data Governance Matters

Recently I had occasion to once again pass along advice to  “Consider removing some of the burden from management teams by utilizing a centralized, federated, or net-centric Data Governance Model.” 

This, as it often does, lead to a specific question and a general discussion. The question? “What does net-centric mean?” Here’s what Wikipedia says: Participating as a part of a continuously-evolving, complex community of people, devices, information and services interconnected by a communications network to achieve optimal benefit of resources and better synchronization of events and their consequences.”

I confess that when I first heard the term and read the definition, I didn’t totally get it. I was really focused on the idea of technology being at the center of the concept. But then I heard some elegant discussions that made be look beyond that factor. Net-centricity is the next logical step when you’re not optimizing components within a closed system or even a set of closed systems.  Rather, it acknowledges that sometimes you have to do your best to manage within “a network of networks.”    

Wow, is that true. And as we all know, networks can be messy, complex, and elusive. 

So what was the inevitable general topic that followed? A discussion of when to adopt a centralized model of data governance, when to design a federated model, and when to go for a net-centric model. That can be a long discussion, but one take-away had to do with the scope of impact you’re trying to make.

Sometimes your field of impact is simply within one department or group (local impact).  Sometimes it is across multiple groups within one organization. (enterprise impact) Sometimes it crosses two or more organizations (multiprise impact). Sometimes you’re aiming to change one little thing across the whole world (global impact).

The larger your field of impact, the more difficult it will be to suceed with a true centralized form of governance. Sure, it’s easy to make rules from a single spot. But it’s very had to follow up on them.  If you need feet-on-the-ground monitoring and reporting, a federated approach may be better for you. (It’s also the better choice if you care a lot about the end results of governance, but are able to tolerate a lot of “local variance” in how you get there.

With a net-centric approach, to Data Governance, you are not only giving up personal oversight. You’re recognizing that different networks have different ways of dealing with similar information, standardization approaches, processes, and protocols. You’re no longer claiming you have to have identical results. Rather, you’re focussing on reaching agreement about high-level goals and objectives and the conditions that need to be in place so you can be certain of addressing those as information moves from one network to another in an appropriate way, according to agreed upon conditions, meeting an agreed upon set of fit-for-use criteria. Of course, you’ll want to address detailed goals and objectives also, but your approach will recognize that collaboration may get exponentially more difficult the more detailed you get.

(Of course, there are exceptions to everything. Introduce the right technology and standards, and it may be desirable to adopt them in all circumstances. Voila! Easy governance!)

But usually, it’s anything but easy. Networks of networks may have too many parts to name. They are messy. Navigating them - much less controlling them - is hard. But it can be worth it when multiprise and global concerns are at stake. So welcome to the 21st century. It’s not for sissies. 

Yesterday, Thomas L. Friedman posted an interesting New York Times op-ed column entitled “From Baby-Sitting to Adoption” about U.S. policy in Afghanistan. No, I am not going to comment on that. But today I heard Friedman say something cool on TV about a totally different subject - he spoke about not letting other describe your problem, and he asserted that those who name a problem thereafter own it. He made some other great comments about the need to frame problems before you start the arduous process of trying to solve them. Suddenly he really had my attention, and I decided to look up yesterday’s column.

(For those of you who are trying to remember where you’ve heard Friedman’s name, he’s the author of ”The World is Flat: A Brief History of the 21st Century” and he’s won several Pulitzer Prizes.)

The metaphor Friedman uses is the different levels of commitment one brings to baby-sitting a child versus aogreeing to adopt the child. Friedman was talking about commitments between two countries - and I don’t want to go there in this blog. But I couldn’t help noticing how useful this metaphor could be to those of us who work with enterprise data assets.

We all face a similar framing situation on an ongoing basis, whether we’re asked to create/refine/review an enterprise data strategy, to implement a data governance program, to advise data stewards, or to help enterprise data management (EDM) or enterprise information management (EIM) programs build strategies, agree on tactics, prioritize efforts, or solve a particular problem.

Here are the questions inherent in all of the above situations as they have been historically framed: 

Who “owns” the data?    Who “owns” the problem?   Who “owns” the solution?

Two problems with this:

1. A conceptual problem - haven’t we all agreed, at least in theory, that the enterprise owns data with an enterprise impact (that is, Business owns data, not IT)!!!

2. A practical problem - even in organizations that agree to #1, I’ve still seen discussions grind to a halt as implications are explored. After all, there usually isn’t a budget line for “the enterprise.” Instead, one or more groups within the enterprise are going to get silo-slammed with negative impacts to their budgets, resources, applications, processes, etc.

So we have a natural tension here: a silo wants to “own” data when it’s to their advantage. But they don’t want to own every problem that is associated with that data. And you can’t blame them.

So the issue resolution framing metaphor of *ownership* is problematic when dealing with cross-functional data issues that impact one or more aspects of gaining access to usable information required to address business needs.

What about a *child care* metaphor?

What would happen if we posit that

• all data belongs to the enterpise

• certain data has been “adopted” by functional groups

• when that data “leaves the house to go to school or public areas, etc.” it is now part of additional systems & networks of activities and must agree to abide by their rules and  work within their protocols

• unless the journey has been “child-proofed” with strong controls, the data may require ”baby-sitters” in the form of data stewards, custodians, and others

• sometimes, additional facilitators are required for naturally chaotic environments such as field trips. (Now we’re stretching the metaphor to include issue resolution sessions, project prioritization analysis sessions, standards-building exercises, and the other types of “special events” that data governance teams get asked to facilitate.)

Now continue down the childcare metaphor path. As a parent, when I sent my children to school, or dropped them off at a babysitter’s house, I was not giving up my parental rights. I was expecting the school/babysitter to address issues that fell within the scope of their system, according to rights and responsibilities we had agreed upon. If an issue had a multi-system causes or impacts, then I expected to be apprised of it, and to be invited to a parent-teacher conference so we could agree on a solution that would have acceptable  impacts within all systems.

(yes, I know it’s more like networks than systems, and I really like the net-centric metaphor. but let’s save that for another discussion, ok?)

So… how would we address data-with-behavior-problems or data-we-can’t-find or data-that-won’t-answer-our questions if we were using a child care metaphor rather than an ownership metaphor?

What would we expect from ourselves and participants if we were invited (or invited ourselves) to take on the roles of 
those-who-plan-issue_resolution_sesions, or
those-who-align_and_prioritize-policies & standards & rules,
those-who-ensure-unbroken-chains_of_custody-for the child

You know, I’m going to have to give this a buncha thought.

- As a mom, I think I have a good idea of what good governance of my kids looks like.

- As an industry analyst, I get asked constantly by analysts/vendors/practice leaders/execs/program leaders/stewards/stakeholders  how we should be framing the next era of data governance in a way to make it operational and focused on performance and conformance and managing risk.

- As a practicing consultant, I know I’ve been willing to babysit other enterprise’s data, but I sure wouldn’t want to adopt it. I wonder if THAT is the sentiment I’ve been hearing from department/silo leaders who are hesitant about participating in data governance programs?  Hmmm…. 

Thoughts?

BTW, following is the quote from Friedman’s column that made me want to write this blog entry. I suggest you read it this way: change the topic under discussion (US levels of commitment within Afghanistan) with another topic (how should Data Governance help participants frame data-related discussions. Then let me know if you agree that we would be doing a service to mommy-and-daddy (the enterprise) if, before we accept a baby-sitting engagement, we ask them (or the silo leadership that has agreed to raise their data babies for them) the questions Friedman lists below.

“Before we adopt a new baby — Afghanistan — we need to have a new national discussion about this project: what it will cost, how much time it could take, what U.S. interests make it compelling, and, most of all, who is going to oversee this policy?”