Previously on datActionable. We have seen the necessity to have a data catalog with a new business perspective to govern the data. I insist on this point, the need is driven by the governance of data not by management of data. The businesses need to take decisions on the data to be able to create value while ensuring the company protection. Typically, business needs to know :

* where are the datasets to serve them for analytics team.

* where are datasets impacted by privacy law, for current compliance but also to analyse impact of a change in the law. And privacy is just an axis of criticality among others.

* what are the datasets the most critical for his business, to protect them from a loss of confidentiality but also to prioritise them in the disaster recovery plan.

* what are the data to put data quality effort on, at a company level not at project local level.

I’ll propose in this article a pattern of organisation with elements for both business function and IT side. For those reading a lot about data mesh : yes, it is data mesh ready.

The challenge to onboard business.

The potential value will be created by the business with data, as the potential loss will be supported by the business. We need them onboard.

This balance of data valorisation with data responsibility is the main enabler of the transformation to a data centric company. The question is now how to identify in the business functions the holders of this topic, at the scale of the company.

Redefining the data steward role and complete it.

The dream would be to find people able to handle both data governance and data management perspectives. And of course, people with time to spend on these topics. Find one four-leaf clover is great, finding the dozens you need is another story.

If we want to rely on people in place and their knowledge, my conviction is that we should not ask these experts to change drastically their perimeter. So, we must be realistic in the role of the Data Stewards and complete them with another role, more focused on data management - I like to call this latest role Data Architects.

I won’t give the full view of role and responsibilities in this article and focus only on the one related to the data catalog.

The accountabilities of the respective roles would be the following :

Data Steward, who have high business knowledge and good IT acumen, are in charge of :

* documenting the Business Objects.

* documenting the restrictions coming with the data, for compliance to external or internal requirements.

* documenting the business requirements on the data, especially the data quality requirements.

Data Architect, who have high data management knowledge and good business acumen, are in charge of :

* documenting the data related informations of applications.

* documenting the Dataset Index.

You may have noticed that I don’t make one of them accountable of the actual usage rights of the data nor the decision on data quality improvement. I reserve this decision to another role : Data Officer. We will see that in episode 3.

Federating Data Steward and Data Architect.

Like mentioned just before, the number of people endorsing Data Steward and Data Architect can raise quickly in the company. Especially if you want to data enable people already in place in the company and you have, by design, not full time people.

Orchestrating this network from an unique central point can’t be efficient : even if we want to break silos, there are some clusters of people dealing regularly together.

The idea is to group them by domain, with a domain lead. This domain lead will functionally report to a central data governance body. Here we have the Data Officer role.

As for Data Steward, four-leaf clover are not everywhere. I propose to have a similar approach by introducing a Lead Data Architect role. As Data Architect and Data Steward, the Data Officer and Lead Data Architect will act as a complementary couple to ensure the construction of the Data Catalog. The Data Officer will push for the Business perspective and the Lead Data Architect for the IT perspective.

The Data Governance Manager, facilitator of the Data Offices.

By grouping Data Steward by domains thru Data Officers, we manage the size of the community but it has its drawback : we may have created another type of silo. To avoid this risk, here come the Data Governance Manager role. This role could be endorsed by the Chief Data Officer depending on your organisation … or not. But the person in charge must at least report to him.

Did I talk about four-leaf clover ? This time it doesn’t work! We are looking for only one person, it is manageable. Nevertheless, to ensure consistency, I propose to introduce the role of Enterprise Data Architect, especially to manage the Lead Data Architect network. Of course, we are only talking of role, one person can handle both if it is possible and more convenient in your organisation. Or, at least, to start the deployment.

This new couple will have the accountability to federate the network. It will have also a facilitation role for the Business Objects which are multi domain. Finally, it will operationally support the Data Officers and Lead Data Architect, acting as expert on Data Governance topics and, thus, preparing the future standardization of the activity.

We have now the federated network principle. We need now to deploy it in the company and deploy it for long term.

How to enroot those roles in the company ?

The first temptation is to rely on the organisations. The weakness of organisations is that they change over time. So we need to find a more stable network to rely on. My thoughts are, since our companies have quality system, the processes are the good entry point.

Connecting the roles and the people.

You should be able to close Business Objects, more specifically Business Objects Views, with the deliverable of the processes. I say only close with. Since, at the time of the design of your processes, the culture of your company was more based on the following triptych: People, Process and Technology rather than Data based. In all case, it is what we already have and it’s a good start to work on the first version of your business oriented Data Catalog.

With these principles, here is how to find your network version one :

* Data Steward, they are the voice of the process owners on the data topic. They are nominated by the process owners.

* Data Architect, we can start by the architect of the applications/products supporting these processes.

* Data Officer, they are closing the gap between organisation and process on data. Nominated by the Head Of Business Functions. Their scope is defined by the process under the responsibility of the function. Interesting thing, you may already find bridges between organisation there : organisation have changed, not the processes.

* Lead Data Architect, as peer of Data Officer, they are located on the IT side supporting the Business Function. Since IT organisation may differs a lot between companies, I can’t say more than that.

* Data Governance Manager, nominated by the Chief Data Officer… or the Chief Data Officer himself like mentioned before.

* Enterprise Data Architect, in the Enterprise Architecture team. He can be nominated by the Enterprise Architect, again it depends on your IT organisation.

How to manage worldwide deployment ?

Again, by referring to your quality system, you should find the path.

If your company is fully integrated, you may tackle the topic by having delegates of the network in other regions, starting by a Data Governance Manager delegate.

By putting a shadow organisation in region while having a delegation and not a duplication of role, you reach two objectives. You gain consistency in your global deployment and therefore ensure the consistency of the catalog. You also have a feedback loop from other regions. They will contribute to the maturity of the catalog by introducing the local constraints.

If you are not so much integrated, typically if your merger and acquisition process is not aiming to fully integrate everything, you need a new level in the role federation. You won’t have the possibility of transversal delegation and may have to deploy in your division and affiliates a complete network, starting by a Data Governance Manager.

However, consistency remains important for the global picture and synergies will reduce the global bill. In that situation, you will have to orchestrate your Data Governance Managers and a new role is necessary. I let you find a name for your company … Global Data Governance Manager ? Data Governance Officer ?

Start small, grow fast.

You have now in mind the target landscape. How can you start its creation ?

Start by a simple dictionary.

Since the beginning of this article I’m talking about roles. They are obviously not full time equivalent, and it is not even the target.

Like I said previously, we don’t aim to have full time Data Stewards or Data Architects role to ensure connection with the company legacy and usual activity. The objective is to avoid having a parallel data organisation, siloed from the business as usual.

What I suggest to start, is even not to have Data Steward until you have the basics: a list of potential Business Objects name organised in domains. Don’t try to do be one hundred percent right, don’t try to build it with systematic interview with businesses : simply gather what is already existing and publish it.

The option I took some years ago, was to have a three months time boxed deliverable with one objective, having a list of 350 Business Objects representing the whole company activity. A Business Object Dictionary.

As input, I given access to heterogeneous models coming from IT, access to the processes, access to the intranet for search, access to enterprise architects and access to local organisations already dealing with data.

We obtained the first company wide Business Object Dictionary, a simple sheet with six columns :

* Data domain.

* Sub data domains : when a business term was too big in term of granularity.

* Business Object name.

* Synonyms.

* Sub Business Object name : when business term was too small and putting at risk the 350 target.

* A description if found somewhere.

We had also a simple KPI : number of Business Objects per domain.

All that printed on A0 paper as wall decoration of a brand new twelve square meters data catalog room. Ready to invite people for feedback. I let you transpose that in our remote working world.

Prime the pump of the Data Catalog.

This basics in place, be ready for the critics. Here is an anthology of what you can hear :

* It’s not your job.

* Who are you to publish that.

* I don’t agree (but I don’t have alternative to propose).

* It’s not precise.

* It’s not what we have in the IT system.

And then some first questions :

* Why do we have nothing in this domain ?

* Why this domain is more represented than the others ? (especially mine)

Fortunately, you will have also people with a willingness to move forward. You may even have counter proposal when an historic data organisation is in place in some area.

After this exercice, you will have :

* Data officer candidates.

* Domain you can consider as allies day one.

* Domain ready for transformation.

All you need to find the sponsors of next steps.

As usual feel free to comment and stay tuned for the next episode : The Data Compliance Quest.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit datactionable.substack.com