Designing categories
When you design your category structure, you must decide the subject area of the categories and who must create, use, and view the governance artifacts within the categories.
- Required permissions
- Properties of categories
- Category structure
- Category collaborators
- Primary and secondary category relationships with governance artifacts
- Categories and workflows
Required permissions
You must have the Manage governance categories user permission to create top-level categories.
Properties of categories
Categories have some standard properties that are similar to properties of governance artifacts.
| Property or behavior | Supports? | Explanation |
|---|---|---|
| Must have unique names? | Yes | The combination of the category path plus its name must be unique. Category names cannot contain the >> characters. Assign a category a name that is general enough to encompass all its artifacts and subcategories. |
| Description? | Yes | Optional. Include a description that helps users who create governance artifacts know what to add to this category. |
| Add relationships to other categories? | Categories have hierarchical relationships with their subcategories and their higher-level categories. Subcategories inherit collaborators from their higher-level categories. Categories that have different top-level categories can't have relationships with each other. | |
| Add relationships to governance artifacts? | Yes | Most types of governance artifacts are organized in categories. Governance artifacts can have primary and secondary categories. |
| Add relationship to asset? | Yes | See Asset relationships in catalogs. |
| Add custom properties? | Yes | See Custom properties and relationships for governance artifacts and catalog assets. |
| Add custom relationships? | Yes | See Custom properties and relationships for governance artifacts and catalog assets. |
| Add custom roles? | Yes | You can create custom roles for categories. See Custom roles. |
| Import from a file? | Yes | See Importing and exporting categories. |
| Import from a Knowledge Accelerator? | Yes | All Knowledge Accelerators include multiple categories. See Components of Knowledge Accelerators. |
| Export to a file? | Yes | See Importing and exporting categories. |
| Managed by workflows? | No | Category creation and management are not subject to workflows. However, categories are included as part of workflow definitions. See Categories and workflows. |
| Specify effective start and end dates? | No | Categories do not have start and end dates. |
| Assign a Steward? | No | Categories have owners instead or stewards. |
| Add tags as properties? | Yes | See Tags. |
| Assign to an asset? | No | Categories are assigned to governance artifacts only. |
| Predefined categories? | Yes | The [uncategorized] category is predefined and contains predefined governance artifacts. See Predefined categories. |
Category architecture
Some common strategies for designing the category architecture include dividing high-level categories in these ways:
- By business units, such as Hardware, Software, and Services, and then by departments, such as Marketing, Finance, and Human Resources.
- By subject areas, such as customers and products.
You can create as many top-level categories and subcategories as you want. You can create categories to organize subcategories and that do not have any artifacts. For example, one section of the category structure for the Knowledge Accelerator for Financial Services looks like this:
Knowledge Accelerator for Financial Services
Business scopes (0 governance artifacts, 29 subcategories)
Custom Insight (0 governance artifacts, 4 subcategories)
Customer Insight - Contact Center Optimization (271 business terms)
Customer Insight - Customer Lifetime Value (258 business terms)
Customer Insight - Optimize Offers And Cross Sell (307 business terms)
Individual Customer Profile Analysis (110 business terms)
Try to design category structures so that categories do not overlap, even if governance artifacts can fit into more than one category. For example, in the Knowledge Accelerator for Financial Services, the business term Email Address belongs to the following primary category and 6 secondary categories:
Category collaborators
Users must be collaborators in a category to view the details of the governance artifacts in that category, or to create governance artifacts in that category.
Category collaborators have roles that control which actions they can take within the category:
- Owner: Manage the category, its artifacts, and its collaborators. Owners can assign any category role, including the Owner role, to other category collaborators.
- Admin: Manage the category, its artifacts, and its nonowner collaborators. Admins can assign any category role, except the Owner role, to other category collaborators.
- Editor: View the category and manage its published and draft artifacts.
- Reviewer: View the category and its published and draft artifacts.
- Viewer: View the category and the details of its published artifacts.
- Custom role: You can create a custom role that has a custom set of permissions to control which actions collaborators can take within a category. See Custom roles.
Category collaborators can have more than one role assigned. Subcategories inherit the category collaborators with their corresponding roles from all parent and higher-level categories. Collaborators in a subcategory have the roles that they are assigned in the subcategory plus the roles that they are assigned in all higher-level categories. See Multiple roles in the category hierarchy.
In general, provide users with the minimum permissions at the higher levels of the category hierarchy. Add roles with more permissions for specific subcategories.
By default, top-level categories automatically have the Public access group as a collaborator with the Viewer permission. However, only users who also have the Access governance artifacts or Manage governance categories permission are included in that group.
Category collaborators fall into two main groups:
- Catalog members who work with data assets and need to view governance artifacts.
- Governance team members who need to create or assign governance artifacts.
Catalog members who work with assets
All users of Cloud Pak for Data as a Service have these permissions:
- View the names of the governance artifacts that are assigned to assets in a catalog or project.
- Assign governance artifacts to assets in the catalog or project, if they have the Editor or Admin role in the catalog or project.
However, to view the details of governance artifacts, catalog members must have the Access governance artifacts user permission and the Viewer role in the category.
The catalog members who work with data assets and need to view the details governance artifacts can include data scientists, data engineers, business analysts, and machine learning engineers. These users work with data assets to prepare data, analyze data, or build models. Typically, you want all catalog collaborators to be able to view the governance artifacts that are assigned to the assets in the catalog.
The default category role of Viewer that users inherit from the Public access group is sufficient for catalog collaborators.
Governance team members
The governance team includes the people who curate data by importing and enriching metadata and the people who create governance artifacts.
The following table summarizes the minimum category collaborator roles for each type of governance goal.
| Governance goals | Actions on governance artifacts | Category role |
|---|---|---|
| Add enriched data assets into catalogs | Assign governance artifacts to assets | Viewer |
| Implement the governance framework | Create governance artifacts | Editor |
| Review the governance framework | Review governance artifacts as part of workflows | Reviewer |
| Manage the governance framework | Create subcategories and add collaborators | Admin or Owner |
Give these users a user role that includes the Access governance artifacts permission so that they are included in the Public access group. These users have the Viewer role in all categories by default. You can give them roles with more permissions in the appropriate subcategories.
For users who perform metadata enrichment, assign them the Viewer role in the subcategories that contain the artifacts relevant for their metadata enrichment tasks. The Viewer role is sufficient to view artifact details and assign artifacts to assets.
For users who create governance artifacts, assign them the Editor role in the subcategories in which they need to create artifacts. If users also need to create subcategories, assign them the Admin role.
The Reviewer role is useful to identify users who are responsible for reviewing governance artifacts in workflows.
Primary and secondary category relationships with governance artifacts
Categories can contain these types of governance artifacts:
Data protection rules are not contained in categories.
Categories and the governance artifacts that they contain have two types of relationships:
- Primary
- Mandatory. The category owns the artifact and determines who can manage it. Every governance artifact has one primary category that is assigned when the artifact is created.
- Secondary
- Optional. The category includes the artifact. An artifact can be included in any number of secondary categories. A secondary category is an alternative way to group and discover artifacts.
A category can have both primary and secondary artifacts.
Users must have permissions in the artifact's primary category to view or manage the artifact.
Categories and workflows
You can configure fine-grained control over governance artifacts by combining categories with workflows. Workflows enforce task-based processes to control the creating, updating, and deleting of governance artifacts. You specify the number of steps in a workflow and who can perform the task for each step. Each workflow controls a combination of categories, artifact types, and actions. Assignees are notified when they must perform a task for a governance artifact that corresponds to a step in the workflow. The assignees for a workflow step can cancel the permissions that are provided by category roles.
For example, if a workflow step specifies that reviewers for creating an artifact must have the Admin role in the category, then only collaborators who have the Admin role are assignees for that task and can create artifacts. A collaborator with the Owner role but not the Admin role is not an assignee and cannot create artifacts, even though the Owner role includes the permission to create artifacts.
Learn more
Parent topic: Categories