Basics of Setting Up the Glossary

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:

  1. At the highest level there is a Community named Data Governance Council. The Data Governance Council owns a number of Domains:
    1. one for each Asset Type, that will contain newly requested Assets for these Asset Types.
    2. possibly, glossary domains that are universally in use.
  2. Within Data Governance Council there are Sub-Communities for each department such as Finance, Operations, etc.
  3. 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

Glossary Steward

Community Steward

Domain Steward

 Steward Subject Matter Expert Stakeholder Where to set this in the tool?

create/edit/remove sub-communities

 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

 

Asset Types

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.

Status 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.


The envisioned lifecycle in terms of six Status transitions is illustrated below:

Workflow Definitions

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. 

  1. Propose New Business Term : Business Term starts in Candidate Status.
    1. Propose New Business Term Workflow Walk Through
    2. Propose New Business Term Design and Implementation
  2. Onboarding Workflow : Business Term goes from Candidate to Onboarded Status, or Rejected Status in case considered ineligible.
    1. Onboarding Workflow Walk Through
    2. Onboarding Workflow Design and Implementation
  3. Approval Workflow : Business Term goes from Under Review to Stakeholder Approved Status.
    1. Approval Process Walk Through
    2. Approval Process Design and Implementation
  4. Request Change : Business Term reverts from Approved Status to Under Review Status, invalidating its approval.
  5. 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.