The Universal Facts About How Data Responsibilities Work, In All Organisations – Part 5 of 5
In Part 4, I explained why data ownership is still needed and how Data Owners depend on the other roles to be really effective in fulfilling their obligations. In this final part, I explain what Data Custodians and Data Stewards are; and wrap-up with a few suggested next steps.
Please read my Disclaimer by clicking here.
No data governance series would be complete without mentioning Data Custodians and Data Stewards. To round this series off, here's a very brief explanation of these roles, linked back to some of the concepts that have been introduced in previous posts.
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, in line with some of the ideas in Part 2). 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.
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 (see part 3) 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 discharging 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 Function 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.
Going back to Part 1 and Part 2, the foundations are really, very simple. The basic concepts align to how every organisation works and anyone should be able to understand them. Part 3 and Part 4 explain why various other 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:
I hope you’ve found this series on data responsibilities interesting and useful. I’d love to hear any feedback that you have: is there anything you agree or disagree with? Is there anything you’ve found particularly helpful or that you think I could have made clearer or done better?
Please read my Disclaimer by clicking here.
No data governance series would be complete without mentioning Data Custodians and Data Stewards. To round this series off, here's a very brief explanation of these roles, linked back to some of the concepts that have been introduced in previous posts.
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 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, in line with some of the ideas in Part 2). 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 (see part 3) 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 discharging 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 Function 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.
Wrapping up
So there you have it. A nice, simple overview of how data responsibilities work.Going back to Part 1 and Part 2, the foundations are really, very simple. The basic concepts align to how every organisation works and anyone should be able to understand them. Part 3 and Part 4 explain why various other 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 series of posts 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?
I hope you’ve found this series on data responsibilities interesting and useful. I’d love to hear any feedback that you have: is there anything you agree or disagree with? Is there anything you’ve found particularly helpful or that you think I could have made clearer or done better?
Comments
Post a Comment