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 the 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 needs to be done in addition to people's "day jobs".

The great thing is that working out who is responsible for data is extremely simple and is based on the fundamental way any organisation works. Data ownership and related concepts become more comprehensible when understood within the context of established foundations of data responsibility.

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 remarkably 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.

In this article, I will provide a straightforward and clear explanation of how responsibility for data works in any organisation, including a brief overview of common ownership structures and how data roles (owner, steward, custodian) align with an organisation's operational framework.

Starting at Ground Zero

Personal Accountability in Data Capture and Handling

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 a shop, or in 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 misspell 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’s Role

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 (guardrails or a defensive platform), 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 on that 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.

Second-Degree Accountability

What if they are given data by someone else?
Perhaps they've received a partially completed form and are using the data they've been given to perform some calculations, while capturing additional 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 was responsible for it at the time of capture. However, from the moment someone receives data, they become responsible for what they do with it.

If they spot that the data is inaccurate, then they can either

1. Choose to take that into consideration
   1. contact the person they received it from,
   2. log and escalate the issue,
   3. or seek to correct it somehow)
2. Or decide to knowingly use the data, despite the fact that it's wrong.

The decision is their responsibility.

Back to 1st-Degree Accountability When Data Exchanges Hands

This leads us to a similar question: What about when they pass the data to someone else? At this point, their decision to pass it on, who they are passing it to, and whether or not they notify the person (or system, or process, or whatever) 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 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 do with the data when they have it, including capturing it, editing it, processing it, storing it, transferring it, deleting it, or passing it on.

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, 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 organisation 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 “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.

Key Roles in Data Management and Consequent Ownership Distribution

‍

Business System Ownership: For Accountability.

Now that the basic and universally true concept of responsibility for data has been established, and before I delve into "Data Owners" and the like, I'd like to take a 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 how amazing a 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 similar, you need someone who can complete that action.

In large organisations, where there are numerous systems and competing priorities, as well as 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 genuinely care about the system
• Have a budget to make changes if necessary
• Generally not someone in IT who runs the system on behalf of someone in the business and is therefore just there to keep the lights on, with 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 it can be ineffective if 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 the Business System Owner.

Often, the right Business System Owner (BSO) is relatively senior and typically manages the teams of people who are the primary or sole users of a system (although this is not always the case).

.

📌 Why the detour to system ownership?

First, if you assign the correct Business System Owner when you assign Data Owners, and 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 significantly harder, or in some cases, virtually impossible, meaning that their success will then be entirely dependent on the talents and experience of the individuals appointed to 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?

• 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 of 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;
• 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 the 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 proactive action to do so, and can be held to account if they don't.

This is a step that many organisations do not take, and you can indeed establish data management arrangements that work without it. However, I can assure you that when a 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.

📌  Overview of a BSO’s responsibilities, ownership, and accountability

A Business System Owner can be responsible for governing the data within their system, ensuring that users adhere to their rules, and controlling the flow of data 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 with the facts established 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 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 because it provides a point of contact for implementing changes to a process that 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 to resolve the problem.

📌 However, just as with Business System Owners, you can take the role of Process Owner a step further.
You do this by making them responsible not only for the process itself, but also for how data is managed within that process.

This responsibility comes with the same constraints that apply at an individual level:

• They are responsible for capturing and processing data within their process.
• They are also responsible for how that data is passed on to other processes, including providing clarity on how the data should be used by downstream processes.
• However, they are not responsible for the data they receive as input.
• Instead, they are expected to push back on poor-quality input data and log any issues that arise.

When set up this way, process-level data ownership becomes both complementary to other roles and very powerful in practice.

I hope that the concept of responsibility for data, which applies at an individual, team, organisational, and role-specific level, is becoming clearer as you consider each of these roles in a consistent manner. This way of thinking also naturally aligns with 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:

1. Data Producer roles (i.e., if you're the producer of data, you are responsible for its production) and
2. 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 point, and when producing or consuming data, they are responsible for the way 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 outlined so far, on their own, don’t provide the kind of robust, end-to-end "data ownership" that is often required for enterprise-wide data management to work effectively.

Also, while these roles and responsibilities may seem to overlap, if implemented properly, any overlap is entirely complementary and will not be duplicative at all, as it leads to constructive collaboration between roles to achieve better ways of working.

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.

Data Owner: Harmonising an orchestra

📌 Why do you need data ownership when you've established all these other responsibilities?
Whilst everything I've explained 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 for which the data was not originally captured. 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”:

1️⃣ Owns a Dataset

The first type of Data Owner is the owner of a particular “data set”.

• The responsibilities of this type of Data Owner very clearly follow the duties described above.
• 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.
• 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 misused.

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.

📌 Identifying a Type 1 Data Owner
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.

2️⃣ Data Domain Owner

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 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 the 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 on to 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, network folder, 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.

They are an "owner" of the container, not the contents of the container.

Overlap with Business System Owner?

A System Owner is generally 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's also sometimes used interchangeably with terms such as “Data Champion”, “Data Curator”, “Data Keeper”, “Data Trustee”, and various others, which is why each role in a data management organisation must be clearly defined to avoid confusion.

So, for the purposes of this post, I’m going to introduce two types of Data Stewards who are helpful to support a Data Domain Owner in fulfilling their obligations.

The term "steward" is chosen because it conveys 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, this role involves a governance position.

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

Domain Data Steward

The first type of Data Steward, which we could call a “Domain Data Steward”, typically reports to a Data Domain Owner and is responsible for engaging across business areas related to their particular Data Domain, such as 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 working for them are responsible for fulfilling their accountabilities.

Functional Data Steward

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 who report to senior management at a local level, assuming responsibility for functional data ownership without the need for a separate Data Owner role to be 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 with how every organisation works, and anyone should be able to understand them. The combination of these roles and responsibilities is 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 with 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 message.
• What will you do differently to simplify and clarify how data responsibilities work in your organisation?

‍

Thanks for reading Modern Data 101! Subscribe for free to receive new posts and support our work.

MD101 Support ☎️

If you have any queries about the piece, feel free to connect with the author(s). Or feel free to connect with the MD101 team directly at community@moderndata101.com 🧡

Author Connect