The Universal Facts About How Data Responsibilities Work, In All Organisations – Part 2 of 5
In Part 1 of this series of posts, I introduced the basics about data responsibilities, starting from the very bottom of an organisation. In summary, I explained that anyone who captures or processes data is responsible for it while it is in their possession. In this part, I work up the organisational hierarchy and explain how these basic responsibilities naturally extrapolate upwards.
Please read my Disclaimer by clicking here.
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?
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.
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 following posts, 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.
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.
Please read my Disclaimer by clicking here.
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 following posts, 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.
Comments
Post a Comment