Building Data Ownership

The discussion of data ownership has been washing around the industry for a long time. As I’m celebrating the 20th birthday of Practical data Migration this year, I thought I should share how we handle it and whether there’s anything in there that can help you.

I’ll start by dispelling a significant myth.

Data ownership is a metaphor not a statement of legal exactitude. The frontline staff and their line management no more owns the data than a bus driver owns the bus. It could be that they have custodianship for a short while and an obligation not to trash it, wilfully or otherwise. They may also have personal legal responsibilities due to its potential risk if misused (I’m thinking health and safety here). But the ownership lies with the organisation.

Metaphors are a figure of speech in which a word or phrase is applied to an object or action to which it is not literally applicable. They highlight points of similarity not identity. So, which of the attributes of ownership are we highlighting here? Certainly not the ability to sell data for the data owner’s benefit. Nor are we talking about the data definitions. Those are, in general, officially decided by the technical side of the business who control the metadata. The users are restricted to the creation, transformation, and destruction of individual items within the given framework. Some Data Owners don’t even have the access permissions to do that.

So much for the business view. Next let’s look at why we make it as tough as possible for ourselves when it comes to recruiting Data Owners. On a typical data centric project, we techies gather in examples of data usage and from that construct our metadata models. We may pay the front-line folks the curtesy of a visit to review any locally developed solutions, but mostly we don’t take any of that too seriously and prefer to rely on “proper” data sources in well-structured repositories.

We have now inadvertently taken on the ownership role, at least of the creation of the metadata. We will inevitably have to speak to our users to resolve some semantic issues. And here may start to encounter a hint of the resentment that our high-handed approach has generated. From a user perspective we then disappear for a while. When we reappear what we present as the solution does not match their expectations but because they have not been party to the compromises that are a natural part of creating any but the simplest of data sets, they have no grasp of why what is delivered is not exactly what they asked for.  We then have the gall to try to foist onto them a poorly explained ownership role, often with no extra remuneration.

We may try to deny it but, having taken de facto ownership of the task of creating the data structures, we also take on board the ownership of the result. At least in the eyes of our business colleagues.

In Practical Data Migration we try to avoid this on two levels. We engage with the business from the outset in all the decisions about data via the DQR process. This is done as equal partners via a data quality board. A thousand small decisions are easier to digest than a single fait accompli. When we leave a project, we leave behind a fully functioning mechanism for managing the business-technical relationship with our business domain experts. Plus, a stack of issues that the project did not have time to resolve in the urgency of delivering to time.

At a more senior level we don’t talk about data. We talk about turning systems off. We point to our plan on a page where we have two red dots on the timeline. The second is the data migration itself. The first is for a meeting where the authorisation for decommissioning of data stores will take place. Those people with the responsibility of making that decision are our data owners.  We start recruiting them from the very start of the project. The earlier the better. We get them to identify the redlines that must not be crossed if they are to sign off on the decommissioning. Again, after our project work is completed, you have self-certified Data Owners.

I realise that my experience is narrow, not in the breadth of business sectors I’ve worked in, but because I have only worked on transformation projects for the last 35 years. I do not know what your compelling event equivalent would be. It could be compliance. It could be efficiency. It could be productivity. It could be profitability. Focus the seniors on the business goal not the mechanism.  Look on your business colleagues as part of a virtual team you are consciously building. And start both sets of engagement from your first day on the project so role misunderstandings are not allowed to build.

however, if you want to hear from one of the most experienced and successful consultants when it comes to changing the strategic view of the C-suite on the centrality of data management beyond the tactical necessity of a data migration, come listen to David Salisbury at Data Migration Matters (https://datamigrationmatters.com/)