Community and Domains Structure
For our data governance organization, we follow the centralized approach as described in OMDP Step 8 – Identify Communities and Domains. It is set up as follows:
- At the highest level there is a Community named Data Governance Council. The Data Governance Council owns a number of Domains:
- one for each Asset Type, that will contain newly requested Assets for these Asset Types.
- possibly, glossary domains that are universally in use.
- Within Data Governance Council there are Sub-Communities for each department such as Finance, Operations, etc.
- Each of these sub-communities own their local glossaries or data dictionaries.
Following an example that follows this pattern:
With this set-up, we can start defining the Resource Role Types and what responsibilities they have. The most exhaustive approach is to have one accountable Resource Role Type at the level of the organization (chief data steward and glossary steward), community, and domain, and three – responsible, consulted and informed – Resource Role Types at the Asset level. This would result in the following organigram.
Depending on your needs, you can skip one or more levels.
Resource Role Types
the following responsibility matrix is augmented with the default settings in the software. For an overview, we refer to Role Types for more.
|RACI Role Type:||Accountable||Responsible||Consulted||Informed|
|Resource Role Type:||
Chief Data Steward
|Steward||Subject Matter Expert||Stakeholder||Where to set this in the tool?|
|X||edit permissions pane, see Managing Users, Roles, Permissions|
|create/edit/remove domains||X||edit permissions pane|
|create/edit/remove assets||X||X||edit permissions pane|
|create/edit/remove attributes and relations||X||X||X||edit permissions pane|
|create/edit/remove comments||X||X||X||edit permissions pane|
|create/edit/remove attachments||X||X||edit permissions pane|
assign roles to users
|X||edit permissions pane|
start/stop workflows and reassign tasks
|X||X||workflow configuration pane (specific per workflow), see Packaged Workflow Walk-throughs and Managing Workflows|
For this use case, the Asset Types to be considered are Business Term and Acronym.
See the Data Governance Operating Model cookbook’s section on Business Assets for details of the attribute types and relation types for these Asset Types.
For every identified Asset Type, it is important to agree on the possible milestones, i.e., Status Types, the instances can go through. For example for the business term Asset Type, the Data Governance Council has agreed upon six Status Types that characterize different phases in the lifecycle of this Asset Type.
Candidate > Onboarded > Under Review > Approved
- Candidate : the initial state of a business term that has been requested on the Dashboard.
- Onboarded : the state of a business term after its request has been accepted (by the Chief Data Steward), and its ownership has been determined (in agreement with the respective Domain Steward).
- Under Review : the state of a business term while it goes through an approval process.
Approved : the state of an asset after it has been positively approved.
Rejected: the terminal state to which a candidate business term goes that is not considered for onboarding.
Obsolete: the terminal state to which an approved term goes after being in use.
Some notes before we elaborate on the workflows:
- We illustrate these five workflows for the asset type Business Term. However, they may be adapted for other Asset Types.
- All the Workflows are deliberately kept minimalistic. Additional email notifications could be introduced at a later stage.
- When deployed, the DGC software will generate automatically for every User Task, default time periods for reminders, deadline, and escalation of the User Task.
The above diagram shows five Workflows that define the transition between these five Status Types.
- Propose New Business Term : Business Term starts in Candidate Status.
- Onboarding Workflow : Business Term goes from Candidate to Onboarded Status, or Rejected Status in case considered ineligible.
- Approval Workflow : Business Term goes from Under Review to Stakeholder Approved Status.
- Request Change : Business Term reverts from Approved Status to Under Review Status, invalidating its approval.
- Request Deletion : Business Term goes from Approved to Obsolete Status.
Note: this only concerns the happy path to approve a Business Term without considering the relation with Data Assets yet.
You have to login to comment.