The Universal Facts About How Data Responsibilities Work, In All Organisations

In this article I present a slightly different and simpler spin on how responsibilities for data work in most organisations, plus a few pointers for things companies can do to make data management roles even more effective.

The wonderful truth: establishing who is responsible for data is easy!

It's really common for organisations to struggle with concepts such as "data ownership", "data stewardship", "data custodianship" and the like.?When these ideas are introduced, they are often met with resistance, especially when they are communicated as something "new" that need to be done in addition to people's "day jobs".

The great thing is, working out who is responsible for data is extremely simple and is based on the fundamental way that any organisation works.?"Data ownership" and related concepts make a lot more sense when they are understood in the context of established foundations of responsibility for data.

Even better than this is the fact that the basic responsibilities of anyone in relation to data are universally the same in all organisations.?The way it works is so amazingly straightforward, in some ways it's astounding that the basic facts that apply to every company, anywhere in the world, are not more widely recognised.

So, in this article, I'm going to provide a very simple and clear explanation of how responsibility for data works in any organisation, including a brief overview of some common ownership structures and how the data roles (owner, steward, custodian) can fit with the way that any organisation operates.

Starting at the bottom

When dealing at an individual level, responsibility for data is obvious.?Let's say we're dealing with someone working in a call centre or in a shop or some other role that involves capturing data.?They may have a hard copy paper form that they're filling in, or may be typing data directly into a system.

Whoever they are, they are responsible for capturing the data that they capture.?If they decide not to fill in one of the mandatory fields, that's up to them.?If they mis-spell something, that's not anyone else's fault.

Just think about this scenario for a moment.?There’s no-one else who could possibly be held responsible for what they decide to do.?The organisation that they work for may be able to provide them with better systems or forms, with validation that doesn't allow them to make some mistakes, and may provide them with more training and support; but ultimately, when it comes down to the action of capturing the data, it's their responsibility.

Expanding that out for a moment, the way in which they handle the data is their responsibility too.?If they decide to take a copy out of the office and leave it somewhere insecure, or to send it to someone who shouldn't have access to it, they are responsible for that.

What about if they are given data by someone else??Maybe they've received a partially complete form and are using the data that they have been given to perform some calculations and are capturing more data in the rest of the form.?Are they responsible for the data that they received?

No, clearly not.?The person who captured the data before them was responsible for it when they captured it.?However, from the point that someone receives data, they become responsible for what they do with it.?If they spot that the data is inaccurate, then they can either choose to take that into consideration (and either contact the person they received it from, or log and escalate the issue, or seek to correct it somehow); or could decide to knowingly use the data, despite the fact that it's wrong.?That decision is their responsibility.

This leads to a similar question: what about when they pass the data onto someone else?

At the point that they pass the data onto someone else, their decision to pass it on, who they are passing it onto and whether or not they notify the person (or system, or process, or whatever) that they are passing it onto of the shortcomings in the data, is up to them.?It's their responsibility.?Also, if there are specific ways in which the data should or should not be used, it's up to them to make that clear when they're passing it on.

Once the data is passed on somewhere else, it's no longer in their control.?They cannot be held responsible for things that they don't do to the data, but they absolutely are responsible for everything that they did with the data when they had it, including capturing it, editing it, processing it, storing it, transferring it, deleting it, or passing it onto someone else.

So, we have now established the basic facts of data responsibilities at the lowest level.?In summary, if you capture or process data, you are responsible for it while it is in your possession.?Time to move up a level...

One level up

If you run a team, you are responsible for the conduct and performance of the individuals in your team.?This is a universal truth in most organisations following a standard management structure.

As such, a team leader is responsible for the data that their team captures and processes.?If the team doesn't capture data they are supposed to, or captures invalid, inaccurate data, or mishandles it resulting in security breaches due to the actions that they have taken, the team leader is responsible, just as the individual in their team is responsible for their actions.

Can you see where this is going?

Rolling up and up

This same concept of responsibility for data rolls up an organisation.?If you run a group of teams, you are responsible for all the data that your teams create and process.

If you run a division or business unit or function in a company, you are responsible for all the data that your part of the company processes.

All this responsibility rolls up and up until it reaches the head of the company: the CEO, MD or whoever runs the organisation.

So, there you have it: super simple and totally aligned to how any organisations works.

Simple yet effective

Some people may now be wondering what the big deal is: isn’t what I’ve just described obvious?

On the one hand, yes, it is.?The thing is, when an organisation attempts to put in place more sophisticated and formalised data governance arrangements, there is a risk that the obvious truths outlined above are lost in translation.?No matter what data management structures are implemented, the above will always be true; moreover, the fundamental responsibilities are really important, because they are the foundations upon which any formalised structures will need to operate.

Building on these basic ideas, I’ll now step through several other, more “formalised” roles, which can each play an important part when implementing a set of well-rounded data management arrangements.?The first couple of roles are not always considered to be “core” data management roles but are often necessary and have the potential to be extremely powerful and useful.?In the sections that follow, I’ll also cover some of the classic data roles associated with data governance, to explain how these fit into the simple model of responsibilities that I have already outlined.

Business System ownership: an important and powerful role

Now that the basic and universally true concept of responsibility for data has been established, and before I get onto "Data Owners" and the like, I'd like to make a little detour to a role that is often mis-implemented and massively underrated when trying to manage data effectively.

Let's start with another obvious fact: systems* contain data.?Data does not exist unless it is stored or processed somewhere, and no matter what amazing data ownership framework you come up with, your actual data will be stored in systems.

(* Note for techies and architects: I'm using the term "system" loosely and broadly to mean any kind of technology that data can be represented in, in some way, whether it be an application, database, data object, or whatever.)

As a result, if you want to do something to a system, such as implement a change to it or get access to it to change the data within it or something like that, you need someone that you can get to complete that action.?In large organisations, where there are lots of systems and lots of competing priorities and budgetary constraints, it's particularly important to have someone who can be held accountable for each system.

However, the person needs to be in a position where they care about the system and have budget to be able to make changes if necessary.?This person generally shouldn't be someone in IT who runs the system on behalf of someone in the business and who is therefore just there to keep the lights on and has no vested interest in its effective operation.?It also can't be someone in the business who is only responsible for day-to-day operations but has no budgetary responsibility.

It's common for "system ownership" to be established but for it to be ineffective because the wrong person has been appointed.?This isn't a sign that system ownership isn't worth establishing, it's a sign that the wrong person has been identified as Business System Owner.?Often, the right Business System Owner is relatively senior and often runs the teams of people who are the main or only users of a system (although this is not always the case).

Why the detour to system ownership?

First, because if you assign the correct Business System Owners, when you assign Data Owners, and when you also combine this with the formalisation of the fundamental responsibilities for data that I outlined previously, the Data Owners will then be able to leverage these other roles to be effective in fulfilling their obligations.?Without these other roles and responsibilities being formalised, Data Owners' jobs become a lot harder or in some cases virtually impossible, meaning that their success will then be totally dependent on the talents and experience of the individuals appointed into their roles rather than through organisational empowerment.

Second, there's the opportunity to supercharge the system owner role.?This is where you can take a System Owner from being a key supporter, to being an absolute cornerstone in your data management strategy.

How?

By making Business System Owners responsible for the governance of the data in their systems.?What does this mean??It means making them responsible for knowing what data is coming into and going out of their system; for checking the quality of data as it's fed into their system from elsewhere and flagging when it's poor quality; for putting in place validation rules so that people can't directly input invalid data and for reporting on the quality of the data in their systems; and for putting in place mechanisms to secure the data in their systems and to manage the transfer of data to anyone else or to any other systems, including establishment of data sharing agreements before datasets are transferred downstream.

If you make this shift, it really transforms the role.?It means there's someone who cares about establishing these mechanisms for maintaining the data, who should take pro-active action to do so, and can be held to account if they don't.?This is a step that many organisations do not make and it is true that you can establish data management arrangements that work without it, but I can assure you that when this kind of clear set of responsibilities is established, it can result in a step-change.

Notice for a moment the similarities in this supercharged Business System Owner's role and the role of an individual in relation to data.?It's very similar.?A Business System Owner can be responsible for governing the data that's in their system, for making sure that users of their system follow their rules, and that they control the flow of out of their system.?They cannot however be responsible for the data that is passed into their system and can only be responsible for the data when it's passed out insofar as a data sharing agreement is put in place.

Also notice that a Business System Owner is not directly responsible for the data itself, within their system, unless they also run the teams of people who capture and process the data in their system.?They absolutely can govern the way that the data in the system is captured and processed, for example by implementing validation and data quality rules, but they can only be responsible for the things that are in their control.?This aligns to the facts established in before.

Process Owners - for completeness...

Given that I've touched on Business System Owners, I thought it was important to address the concept of "process ownership" too, especially for organisations that already have such a role in place.?Moreover, even if you only have the concept of localised process ownership, if you consider that a process has a set of inputs, which will include data inputs; that a process then performs a set of tasks, which almost always involves processing data; and then a process delivers some outputs, which often also involve data... I hope that you will have already spotted the pattern of responsibility that an organisation has an opportunity to follow and leverage.

A Process Owner is an individual that has been assigned as accountable for an end-to-end process, which may often span multiple organisational siloes.?In a simplistic data management model, having Process Owners in place is useful to have someone to go to in order to implement changes to a process where that process is driving problems.?For example, if it’s identified that a particular step in a process is driving poor quality data, then there is an individual who is accountable for that process and has the resources to make changes and rectify the process step in order to resolve the problem.

However, just as with Business System Owners, if you take the role of Process Owner a step further and also make them responsible for the way in which data is managed throughout their process; with the same constraints as those that apply at an individual level i.e. they are responsible for capture and processing within their process, and for the way data is passed onto other processes (including clarity on how the data should be used by downstream processes), but not for data that they receive as inputs, which they have a responsibility to push back and log issues with... this type of ownership also becomes complementary and very powerful.

I hope that this concept of responsibility for data, which applies at an individual level, team level, organisational level, and within the span of control of roles such as Business System Owner and Process Owner, is starting to become clearer as you think about each of these roles in the same way.?This way of thinking also naturally aligns to the next two roles that I am about to introduce.

Data Producers and Data Consumers

I've nearly got to data ownership roles, but before I get there, it's worth making a general point that all of the responsibilities that I have described so far, are variations on Data Producer roles (i.e. if you're the producer of data, you are responsible for its production) and Data Consumer roles (i.e. if you consume data, you have a set of requirements for what you want to consume and must use it in line with the purpose for which the data was originally created).

At a basic level, anyone who captures or processes data is responsible for how they capture or process it.?Most people are both producers and consumers of data at some stage or other, and when producing or consuming data, are responsible for the way in which they do so.?The same concepts apply to Business System Owners and Process Owners, and these all offer opportunities to formalise roles across your organisation to deliver a far more powerful network of responsibilities supporting good data management practices.

However, the roles and responsibilities that have been outlined so far, on their own, don’t quite provide the kind of robust, end-to-end "data ownership" that is often required for enterprise-wide data management to really work.?Also, whilst these roles and responsibilities may seem to overlap, if implemented properly any overlap is totally complementary and will not be duplicative at all, because it leads to constructive collaboration between roles to accelerate to better ways of work.?Each role is an important enabler for all others, which can make a huge difference to the effectiveness of data management practices across an organisation.

Why do you need data ownership, when you've established all these other responsibilities and things?

Whilst everything I've explained in the sections above is useful and important to manage data effectively, in most organisations, especially large ones, the problems encountered with data are not found at an individual system or process level.?Instead, they manifest themselves in inconsistencies across multiple systems; or in the misuse of data in scenarios that the data was not originally captured for.?For example, if the same data in three systems, is captured in different ways (for example using different formats and structures), when they feed into a central system, they will clash and cause all kinds of operational and analytical issues.?Likewise, if data is captured for one purpose and then used for something totally different, it could not only result in the wrong outcomes but could also be directly breaking several laws and regulations at the same time!

As a result, one of the critical things that most data management initiatives tackle is cross-system and cross-process alignment, consistency and harmonisation.?Whilst good data management practices are absolutely critical at an individual system and individual process level too, the most common need for "data ownership" is found in the need for common data rules and data governance across multiple systems.

As such, a "Data Owner" is usually established to address this point.

Depending on the data management model that you are following, there are two types of “Data Owner”.

The first type of Data Owner is the owner of a particular “data set”.?This owner is accountable for the content in a data set, for example the official master records of a set of customers, held in a master data source.?The responsibilities of this type of Data Owner very clearly follows the responsibilities described above; however, their responsibilities can be enhanced in relation to governance of the use of their data, with powers to both establish “data sharing agreements” before any data consumers can access the data that they own, and with enforcement powers to remove access and escalate where they find that their data is being mis-used.

In some organisations, the owner of a data set may also be the owner of the system that contains the data and the processes that capture and use the data.?Following the lines of responsibilities lined out in this series of posts, it is usually quite straightforward to work out who this person is and it is usually this person who will most care about the way in which the data is handled, because they are often responsible for both the value driven in the use of the data and the consequences if something were to go wrong with it.

The second type of Data Owner is often referred to as a “Data Domain Owner”, and is responsible for setting the common rules that are followed for a particular set of data that they are responsible for, and for running the governance arrangements that oversee conformance to those rules.

For example, a Data Domain Owner may be appointed for the "Customer" data domain, with responsibility for setting the rules for how Customer data is captured and processed; and then for engaging with the relevant Business System Owners, Process Owners and organisational leaders to ensure that data is only captured and processed in accordance with the standard rules.

As a result, a "Data Domain Owner" can only be directly responsible for data that is created by them or their teams; so in most cases, a "Data Domain Owner" is reliant on other individuals in roles across the organisations to fulfil their obligations, which further explains the importance of establishing the other data responsibilities and system ownership roles.

In some cases, where an authoritative, master source of data has been established, the “Data Set Owner” for the data in the master source may also be appointed as the “Data Domain Owner” for that data as it exists across the organisation, which can significantly increase the empowerment of the individual to drive consistent data management practices for the data that they “own”.?For example, the Customer data managed in a Master Data Management platform may be assigned to someone as both Data Set Owner and Data Domain Owner for Customer data.?This means that they are both able to directly control the data within the platform (within the bounds of the data responsibilities explained in previous parts of this series of posts) and may also set the wider rules and governance for Customer data as it is captured, stored and processed elsewhere across their organisation.

At this point, you will see why it's easy for data management responsibilities to appear to be quite jargon-heavy and complicated, but they really aren't as complicated as they appear.?If you keep going back to the basic concepts of responsibilities that were introduced in the first few sections of this article, the same principles apply.?No matter what role you are fulfilling, you can be responsible for data when it's in your possession but not when it's not.?You can be responsible for governance of data that others use, but your empowerment will be dependent on other roles and structures in your organisation to enable you to discharge your governance responsibilities effectively.

Now I've covered "Data Owner" roles ("Dataset owners" and "Data Domain Owners"), I'll move onto two other common Data Management roles: "Data Custodians" and "Data Stewards".

Data Custodians – looking after the containers of data

I tend to think of Data Custodians as anyone who looks after a "container" of data but who doesn't touch the data in it themselves (unless specifically instructed as a technical action, rather than as a day-to-day responsibility).?By "container", I mean anything that stores data, such as a system or network folder or filing cabinet or anything else that holds data, either temporarily or longer-term.

A Data Custodian looks after data indirectly, but they are not directly responsible for its quality or security, beyond the operation of the processes and controls that are in place on the container i.e. they are an "owner" of the container, not of the contents of the container.

For example, a System Owner is generally a considered to be a Data Custodian (unless their role is beefed up to be more than this and to cover direct responsibility for the data within their system, in line with some of the ideas at the beginning of this article).?They manage the system and make sure the relevant mechanisms are in place to maintain the data within it, but do not touch the data or play any role in setting the rules in relation to the data.

Data Stewards – a broad term!

The term “Data Steward” is used broadly and often quite differently in different organisations.?It is also sometimes used inter-changeably with terms such as “Data Champion”, “Data Curator”, “Data Keeper”, “Data Trustee” and various others; which is why it’s important that each role in a data management organisation is clearly defined to avoid confusion.?A Data Steward in one organisation may be very different to another.

So, for the purposes of this post, I’m going to introduce two type of Data Steward that are useful to support a Data Domain Owner in fulfilling their obligations.?The term "steward" is chosen due to the idea of someone who "looks after" the data; they care about it and play a role in maintaining it, even if in some cases in a governance position.

Data Stewards are the rule-setters and guardians of data.

The first type of Data Steward, which we could call a “Domain Data Steward”, usually reports into a Data Domain Owner, with responsibility for engaging across business areas in relation to their particular Data Domain, for example Customer or Product.?Where a data management structure has been implemented around "Data Domains", a Data Domain Owner is accountable for governing their Data Domain and any Data Stewards that they have working for them are responsible for the fulfilment of their accountabilities.

The second type of Data Steward, which I will label “Functional Data Steward”, is locally aligned to a particular function or business area, with responsibility for their specific business area.?For example, Marketing, HR or Operations.?If a functionally-aligned data management structure has been implemented, then a Functional Data Owner (or possibly a Data Owner for a Functional Data Domain) may have been established, and Functional Data Stewards will work on behalf of this functional Data Owner.?However, it is possible to have Functional Data Stewards that report into senior management at a local level, who assume functional data ownership responsibility without the need for a separate Data Owner role being formally established.?The design of these kinds of roles can vary from organisation-to-organisation, tailored to the way that a particular business works.

The collaboration of people fulfilling these two different types of Data Stewardship roles enables the development of sensible, fit-for-purpose data rules; and also enables oversight and data management, including data quality management, at both a data domain-centric, cross-system level, as well as at a more local, function or business-aligned level.?In the most effective Data Governance structures that I have seen, these two roles have been established in some shape or form, albeit not always using exactly the same labels as described here.

Wrapping up

So there you have it.?A nice, simple overview of how data responsibilities work.

The foundations are really, very simple.?The basic concepts align to how every organisation works and anyone should be able to understand them.?The combination of these roles and responsibilities are important to make the whole work well; and by now I hope that you have a clear idea of how all the various data management roles fit together holistically.

However, there is still quite a lot of data jargon and theory in here, which only works if implemented sensibly and simply.?You don’t need to formalise every role that I’ve explained and in most cases it is more effective to formalise these responsibilities into roles that already exist and to use terminology that an organisation is already familiar with to land the concepts rather than trying to force a totally new way of thinking on people.

To bring this to a close, here are a few questions to ask yourself:

• Do the descriptions in this article align to your understanding or have you had any “ah-hah” moments where you now have a clearer perspective on how these ideas fit together?
• Is there anyone else that you know, who would benefit from this level of understanding??If so, please pass on the messages!
• What will you do differently to simplify and clarify how data responsibilities work in your organisation?