Sunday, January 3, 2010

Who's data is it? (Part 4) - Counter-Point

The past three posts in this series have dealt with negative behaviors or attitudes about the responsibility of data ownership:
  1. It's the vendor's data
  2. It's MY data
  3. It's NOT my data
As I mentioned a the end of part 3, an important factor to consider when looking at any of those situations is the history behind how the team or organization came to be where they are.  Every organization forces behavioral pendulums to swing back and forth between extremes in response to negative outcomes.  What might appear to currently be a negative behavior may have once been a reasonable response to some other negative experience.

For instance, "it's the vendor's data" may well have developed in response to some historical data conversion or data integration project that well over schedule and over budget because data structures were poorly understood by the internal team and the use vendor services was discovered, too late, to be a huge benefit.

Likewise, the "it's MY data" crowd might come from an application support team that has come to understand the value of information integrity and master data, and has developed a sense of protectionism from those goals the hard way: by failing to meet past goals.  "We're responsible for maintaining CUSTOMER data for the company.  If someone else starts using that data without our close direction, then they'll misunderstand what they're looking at and misuse the data."

The philosophy behind this perspective is very reasonable, but the implementation becomes one of closing off access to information rather than increasing and easing accessibility and educating users and other teams on how data should be used.  Rather than maintaining institutional knowledge exclusively within a support team, how to use key information should be exported to the larger enterprise.

People who are focused on executing business processes tend to examine technology and information management from a localized context: what information does this  process need as input and what applications will this process use?  This siloed view lacks the concept that a great deal of value comes from examining the space in between business processes or applications.  In the space between various business applications, there exists an opportunity to gain a higher-level of understanding about information interrelates between those various silos.

Thanks for joining me on this conversation about data ownership.  Personally, I detest the word "ownership."  It has negative historical connotations that somehow suggest to me "ownership of data" implies the "enslavement of data."  But I struggle to find a more appropriate way to refer the concept that someone has certain responsibilities when it comes to managing information.

Perhaps it's a bit trite, but to borrow from the famous Native American proverb about the earth:

We do not inherit data from upstream systems; we provide information to downstream ones.


  1. Paul, these 4 posts about data ownership are really great.

    I share your feelings about the word ”ownership” in the context of enterprise data. As you say, it’s hard to coin an alternative term that expresses what should be the positive and operational meaning of shared responsibility for data in a given organization. You have however contributed with a very well written conversation covering observed negative behaviors and the possible reasons for these.

    All the best


  2. Henrik,

    Thanks for the comment. That swap of "data" as a proxy for "earth" in the quote I put at the end of this post came to me while I was writing, and it's kept me thinking. I wonder if there's further language that we can borrow from that same analogy to replace ownership. Maybe something like tenant. Use of "tenant" as a verb isn't very common, so I'm afraid telling people "instead of owning, think of it like tenanting" would sound awfully contrived. If I come up with better language, I'll definitely be writing about it.