 |
DatActionableI have designed & deployed enterprise level data governance framework across large corporation. On datActionable, I share best practices and foundation principles. Author: Frederic BERNARD-PAYEN
I have designed & deployed enterprise level data governance framework across large corporation. On datActionable, I share best practices. datactionable.substack.com Language: en Genres: Business, Management, Technology Contact email: Get it Feed URL: Get it iTunes ID: Get it |
Listen Now...
S01E04 - The fall of the Kingdom of Process and the birth of the Data Federation.
Thursday, 15 April, 2021
Business functions have now only one word in mind, Data (usually followed by Artificial Intelligence). However, unless you are in a company selling a data product or a data based service, the business is not data itself. It can be a tangible item or digital delivery - like software. Your company is not (or not mainly, or not yet at all) monetising its data, but selling a product or a service.Let’s step back looking at your company. Considering it as a system, a black box. Your customer has requirements and your company provides him the product fulfilling this requirements. Of course, some data can transit from the customer to your company or in the reverse way, but it is still a negligible part of the data you have in your company.What is happening inside is you know-how and you customer doesn’t really care of it, at least until your cost, quality and delivery time are not killing the value he was expecting.Since decades, pushed by standardisation initiatives in the 90’s like ISO 9000 norms, company have documented their activity thanks to process and people and support of some IT tools. The place of the data was limited to some inter process exchanges of deliverables, more close to paper dossier than data like we consider it today. These exchanges were mainly documented along the production chain.What we aim, is to be a data driven company, for data driven decisions, data driven reporting, data driven behaviours. Yes, your organisation will go data centric. Nevertheless, becoming a pure data company is another story.This legacy is there, pretending it doesn't exist is a mistake. We need to enroot data in this ecosystem. Yes, the process kingdom is falling. It doesn’t mean we need to kill the process.Connecting the dots between data catalogue concepts and company processes.So, connecting with quality team of simply by consulting your internal portal, you may find this referential of processes.You should find something like this.Processes, Activities, Tasks : from a pure ISO 9000 perspective, you have set of interrelated or interacting activities that transform inputs into outputs. Sometimes the outputs take the name of deliverables.I won’t deep dive here, but I will insist on the fact these are conceptual. Like the Business Objects and Business Objects Views.Nevertheless, in term of granularity, I have at least some convictions that will frame the model I propose :* For Tasks, they should be associated to limited roles and be executed in a continuous time frame. Interruption can occur, but it is not the standard behaviour.* On one other hand, Activities group these tasks. Activity may have a deliverable for which Tasks were contributors.* Finally, Processes are grouping and sequencing the activities. You should have a process owner. Most of the time this process owner is attached to the organisation executing this process. It will help deployment if your level of granularity of process permits to do such allocation, identifying your data stewards and link them with their data officer.The level of granularity of process is so high that, the only data catalogue concept you can link, is Business Objects. As defined in the Episode 1. It won’t give you a lot of information but, at least, it will help to allocate data sensitivity requirements we have seen in Episode 3.To have a finer level of granularity, we need to go to activity level and link them with the Business Object Views. Activities would create, enrich or simply use the Business Object Views. Tasks should interact too with Business Objects Views, which are naturally the one aggregated at Activity level.What to do with Deliverables of you Business Processes ?The last element I mentioned, in the process repository, was the Deliverables. My opinion is that they are similar in term of granularity with the Business Object Views. Nevertheless, they have been designed a long time before the start of the company data journey. So, it is difficult to have a one to one correspondence.I faced several issues when trying to reconcile them :* They are often document oriented, mixing several concepts.* They have a specific name, like if they were a concept … but are in fact a name given to a state of a concept.* We miss some Business Objects Views, when deliverable are described at process level. It typically hides the inter-activities deliverables.* Done in a top-down approach, the vocabulary is sometimes different from the user one.Depending on your ambition, and on the budget you have, I would suggest two paths :* Either do, for now, a simple mapping matrix between deliverables and one, or many, Business Objects Views.* Or, dusting off the process referential by replacing all Deliverables with Business Objects Views. But it is a long way…Completing the view by adding activities relationship with IT.A last thing, you need to think about, is complementary mapping of Activities or Tasks to IT levels. As the Business Object View is pointing to a Dataset, thanks to Dataset Index, Activity should point to (Dataset) Processing.I’m not adding complexity for the pleasure…Considering the architectural possibilities of today, analysing an application as an indivisible whole won’t give you the flexibility of deployment versus data compliance. Let’s imagine a simple case with an application manipulating both sensitive and non sensitive data. If you want to use Function As A Service platform (like Lambda) to process the non sensitive data, and you don’t have this level of granularity of the description, you will enforce sensitive requirements on the Function As A Service. That will lead to over costs or even show stopper. With evolution of privacy laws, I let you imagine the over constraints you can create.I guess you would like to have now a cheat sheet with the concepts and their relations. Let me think about that for subscribers !Leveraging this connection to rethink the data access and data usage policies.Since decades, yes decades, we are managing group of users of applications. And we are dying of that. People change of job within the company, nobody takes care of removing your access to application … which is not a big deal we say to ourselves. We know that the person stays in the company, his access will be removed if he leaves. But… some data requirements have changed. Your new job purpose doesn’t justify at all the access to personal data you have, thru the application you used ten years ago…In parallel, these access were given from a pure need to know perspective, when you needed to justify why for everything. This is at the opposite of what we try to do : open the data by consent. We try to have a graduated answer to the risks and some data can be available to all employee without any risks.So, today, some people don’t have access to rather open data they could use to create value, while they have access to data they don’t need, and which may create risks. We can change that thanks to a shift to a data centric approach and a mature business process management.If you have all this season articles in mind, we have all the elements.People are working for a company purpose.People job is executing some activities and tasks. These activities and tasks consume and produce Datasets corresponding to Business Objects Views. It’s a no brainer for those people to be able to access and, or, process those data. We need to ensure data requirements, especially compliance one, are known and are fulfilled for the activity. It includes fulfilment on IT systems security, on activity itself and on the person executing the activity.More over, if we don’t have requirements restricting the diffusion of the data within the company, we don’t need to restrict the access to this activity. The idea is to find how far the dataset can be shared, thanks to the requirements coming with the associated Business Object View.* If the Business Object View has no sharing and processing restriction, we have our company open data.* If the business object view has some sharing restrictions, we try to find the higher level of granularity for which it can be opened : Task ? Activity ? Process ? Group of Processes ? and will call it “Purpose”.At the end, anybody working for a Purpose, has access to the data necessary for the purpose, plus to the company open data.New use cases are new company purposesIf somebody has a new use case, and need some datasets limited to a purpose, he can request corresponding Business Object Views to Data Officers, who will do an ad-hoc risk analysis. The access may be granted for this new purpose or not. For POC it will be temporary. If it goes as industrial solution, the access granting would have to be documented by linking the new or modified Activity or Task as consumer of the Business Object View.I let you re-read the episode 2 to define complementary responsibilities of Data Stewards to manage these high level right policies, keeping them at Business Level. These business rules, combined with the attachment to people to purposes, will have to be transformed in technical rules for actual accesses. Here we have some exploration area for automation, and the business case is there for sure when you seen how much you spend to manage individual people access rights.What is next ?That was the season 1 finale. We have an approach to lever the data knowledge and use it to open the data within the company. It encompasses the whole business knowledge of the data and connect the dots with compliance, processes and IT.It doesn’t answer what we will do with these data. We can do a lot of things. What if you have discovered Uranium, would you have use it for power plant, weaponry … or a glow in the dark table for your living-room ?Subscribe now to receive season 2 premiere directly in your inbox … if the show is renewed ;) 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
