In the endless quest to try and simplify the process of implementing data governance, below is one view of the data governance journey as a subway diagram:
The subway view recognises that each path of the data governance journey must support the other paths. If you run into an obstacle you can get off at the next stop. If working through the line in one direction doesn’t work, trying taking the same line in the other direction. Where the lines come together at the same stop you should celebrate this as a critical milestone.
Starting your journey – multiple entry points
You can immediately start your data governance journey from four entry points. When one of these get blocked you can continue on the other lines – checking in at shared stops.
Forget all that fuss about business glossaries
Many data governance initiatives get so caught up in the challenge of establishing a business glossary that they start to think having one would mean they have a “mature” data governance approach.
In reality, having a business glossary established is at the low end of maturity – see also: Business Glossary as Low Maturity.
It’s easy to see why so much focus is paid to business glossaries but this because it’s at the intersection of a number of different journeys. You should come at it from these different directions rather than approach directly.
The Red Line – Governance
This line puts the governance in data governance.
There is a curious problem when we talk about establishing data governance. Conversations can quickly be turned against the effort to establish data governance with calls that it’s “too complicated”, or “technical”, or “not as important as our growth initiatives”.
But it’s a misnomer to think we are “establishing” data governance. This isn’t the right way to think about it at all. There is already accountability for data governance in your organisation – right now. Especially, and particularly if you haven’t done anything to establish it.
The default data governance framework that exists in every organisation is as follows:
- The board is responsible for the organisation’s data (this is often expressed in legislation and regulatory guidelines such as APRA’s CPG235)
- The CEO must manage the accountabilities of the executive team to determine what they are accountable for; by default it should be assumed they are responsible for everything in their divisions, including data
- The Chief Information Officer has typically taken the brunt of data issues so has implemented a number of IT governance mechanisms to push that accountability back to other divisions. For example, ensuring applications have a “business owner” who is responsible for the data in the system. Also, implementing business prioritisation approaches which ensure if there are unresolved data issues it is at least nominally a business decision – rather than an IT decision – to defer the resolution of these.
- All data management is reactive. Meaning we talk only about issues that people have taken the time to raise – even though if we took the time to look we would find many more issues. But it’s not only data quality that’s treated reactively. If we have a strategic initiative that requires a single view of customer we will create one – but only for that initiative, and we will likely ignore the work of others, and we will ultimately put the overall schedule and cost management of that initiative before the outcome of producing a single view of customer.
- Anybody proposing improvements to data management that require funding must demonstrate the value of the initiative without exposing risks that management doesn’t want to hear about.
The red subway line brings this default data governance approach into the light. The line can be entered from either end and the key steps are as follows:
- Executive Accountability – Who is ultimately responsible for data governance? What’s the CEO’s answer to this question?
- Formally Instantiated Data Governance Council – Is the Data Governance Council a formal governance body in the organisation’s overall governance structure? If not, why have it? Why not just have the Data Governance Manager and Accountable Executive(s) represent data governance in other formal forums?
- Decision on Divisional or Data Domain based Data Owners – For some organisations it might be easiest and more appropriate to have a Data Officer for each Division. This allows for a separate data governance implementation per Division. This approach doesn’t solve the problem of managing the end-to-end life-cycle of data domains that cross multiple divisions. So you have to decide. If you have Data Owners per data domain you’ll get more business value from the governance process – but you will have to change people’s job descriptions so that they have responsibilities and authority across divisions.
- Clear Treatment of Data Risk – You have only two choices for data risk. Either everybody is accountable for considering data risk in their responsibilities, or there is also somebody responsible for data risk in aggregate. The organisation’s risk management framework needs to address this and tell the organisation what it has decided.
The Green Line – Data
This line puts the data in the data governance.
The Pink Line – Privacy
Here we are ensuring data governance and the Privacy Officer are on the same train.
In Australia at least, privacy legislation and the Australian Privacy Principles (APP – https://www.oaic.gov.au/privacy/australian-privacy-principles) have driven much of the cross-divisional data governance effort.
The need for Privacy Officers to mentor the principles means you likely have an ally in the organisation that knows the difficulty of implementing data responsibilities, controls, and other proactive efforts.
Without stepping on each other’s toes, the challenge here is to ensure you and the organisation’s privacy officer support each other. The privacy officer is both a “data owner” and a “data steward” in the data governance framework.
By ensuring your data governance approach includes the concept of “virtual data domains” you will be able to help the privacy officer with the following:
- Ensuring the privacy officer can distribute responsibilities in the organisation – just like you need to in order to implement data governance
- Support a mechanism that allows rules to be implemented that apply to certain fields and types of information regardless of which data domain it appears in – this is a “virtual data domain” in its essence
- Collect the information capabilities that implement privacy principles such as anonymization, controlled disposal, GRPR data subject rights, and other “Consumer Data Rights”
- Additional support at architecture review gates, and establishing the boundaries of agile delivery approaches (i.e. what can be done and how before permission must be requested)
The Amber Line – Critical Data Elements
This is where we make the distinction between “doing everything” and focusing on value.
The Brown Line – Data Quality as Performance Improvement
We make the link between data quality and organisational performance.
Connecting Lines
Our network connects to other lines on other networks. Although they aren’t shown there are links to:
Customer Orientation – this connection ensures customer engagement and customer data are managed together
Performance Optimisation – this connection ensures that the performance of the organisation can be understood and optimised using the widest data sets
Asset & Yield Management – this connection ensures data about your assets can be used to both manage the assets themselves and optimise how the assets contribute to revenue
What about the destinations?
When presenting the subway journeys above I was once asked “what about the destinations?” Very good question! The subway journey is supposed to show the effort required to “get there” and to allow us to map where we are. But it’s terrible as showing why we are doing it – where we are trying to get it.
Perhaps the destination is different for everybody – but a generic version might look like this:
For different individual lines the destinations might look like this: