Best practice for grouping the Assets
We are working on designing the operating model, for the same I want to understand what is the best practice of grouping the assets.
We need to group assets by Data Domains such as Customer, Vendor etc.
- Should we create sub community for each data domain to group assets
- Should we create Customer, Vendor etc as an asset of type Data Domain (DDOM) and create relationships with the other data assets to classify them
jigyasayadav
Posted 4 years ago · Edited 1 year ago·Last reply 4 years ago
4 comments
christopherthullen1
·4 years ago · EditedNewly ingested schemas, tables, and columns land by default in “Business Analysts Community” / “schemas”. I typically move the Collibra domain (of type physical data dictionary) that holds them to a community dedicated to all physical data elements.
We therefore have our eight data areas, each as a community, and alongside them, the physical data dictionaries grouped into one community.
This is what we have
All Enterprise (community)
Customer Data Area(community)
Glossary (Collibra domain)
Logical Data Dictionary (Collibra domain)
…
Accounting Data Area (community)
Glossary (Collibra domain)
Logical Data Dictionary (Collibra domain)
…
Physical Data Dictionaries (community)
Database A (community)
Schema A.x (data dictionary domain, moved from “Business Analysts Community” / “schemas”)
Schema A.y (data dictionary domain)
Database B (community)
Schema B.x (data dictionary domain)
Schema B.y (data dictionary domain)
The use of the term “domain” is a little confusing as it refers to two things:
a) data domains, which are our subject areas , owned by a specific owner at the director or VP level in the company
b) and the Collibra domains
In the diagram above, I changed “data domain” to “data area” to reduce this confusion.
You will see in our diagram that we chose not to put physical data elements under the ownership of a data owner. This is because we have many instances where a physical data element can contain information owned by multiple data owners. The link between the data owners and the physical data elements is made via logical data elements or business terms in the following way: physical data element (owned by a technology owner, located in the physical dictonary) <–> business term (owned by a data owner, located in one of the glossaries).
christopherthullen1
·4 years ago · EditedWe have the same debate in my company, specifically for business terms and similar asset types.
Here are two options:
Group all business terms in one domain which of type glossary. We then classify the business terms with the relation “Business Dimension classifies / is classified by Asset”. However, we have to assign data owners and stewards asset by asset.
Create sub-communities for each data domain. And each sub-community has its glossary. This allows us to assign the owner and stewards for the whole data domain.
The physical data dictionary is organized by database and schema and there is no debate for these.
rahulnair1
·4 years ago · EditedHi @christopher.thullen ,
Could you please elaborate on what you mentioned about the physical data disctionary? How do you organize newly ingested schemas, tables and columns? Do you keep them in the Business Analyst Community or do you create separate physical data dictionary for each domain / communities? This is something that I struggling with right now.
Former User
·4 years ago · EditedJigsaya, there are so many factors that play into designing your operating model, there is no best practice for grouping assets. It depends on your data, privileges you want to control, approach to your business glossary, what your data governance objectives are, and your level of enterprise focus to name just a few. Do be careful in thinking about “grouping”. More often than not metadata needs to have a variety of flags / relationships to other metadata - be cautious and purposeful about creating any mutually exclusive groupings. There are many, many ways to lay out your OM - you have a ton of flexibility with the platform, and you’re likely on an iterative journey. Don’t be afraid to jump in, knowing you can change things, later.