Catalog admins

Aperture Data Studio’s new Data Catalog and Governance Module handles a broad mix of use cases ranging from basic to mature data governance compliance, reference data management, analytics governance, and more.

We provide a number of out-of-the-box solution template packages to act as a fast-track starting point for your needs, but the module can be flexibly configured to allow you to specify what metadata you want to capture, the relationships between these types of metadata, and the types of interest that you want to enable against these.

The Catalog has a few standard types of Object that can be captured, including:

• Technical Metadata: Systems, tables and columns can be auto-harvested using database connectors.
• Ruleset Information: Rulesets, rule inputs, rule groups and rules) can be promoted from the designer interface to the Catalog.
• Validation Results: Resultsets allow the results of validation steps from the workflow designer to be passed to the Catalog so that they can be tied to the context.

However, beyond this these is complete flexibility to capture additional metadata items so that you can use the Catalog to represent, for example:

• Glossary of terms and definitions.
• Logical data model (for example subject areas as a parent of entities as a parent of attributes) which can be linked to physical data (for example attributes linking to columns to drive a common language around describing the data).
• Analytics models and related information (for example the purpose for which they serve, their current status, the LLM/technology underpinning it, the jurisdiction of the model).
• Policies and linked related data.
• Business processes and the data fueling each.
• Business organizational context such as business units, departments, regions so as processes can be mapped against these.

To update the data model, Catalog Admins should navigate to the gear icon on the homepage to access the data model configuration page. Within this area of the product you can specify new Object Types, fields to capture against these, associations between different Object Types, and the types of interests for each Object Type.

Object Types

To specify additional metadata to capture within the platform press the create new Object Type button and follow the steps to specify the required information:

• Name: This is used for in app menus and for defining the URL path when navigating around Objects of this type (for example an Object Type of Policy would have a URL with the format …/Policy/…).
• Plural: This is used for the homepage to represent this type of Object.
• Approvers: If you wish for changes made by users to Objects within this Object Type to trigger an approval, please specify the user or group of users whom you want to approve these changes.

Further customization options enable you to display certain Object Types on the homepage if needed, allowing users to navigate to them directly.

Field Types

By default, users only set a name value for new Objects. However, additional fields can be configured to capture additional data about the Object.

When configuring the fields for the Object, various options are available to allow you to specify the data type captured by each field, the layout, and present of the field within the form including:

• Data type: Specifies the type of information being captured. This then drives further configuration options of Component Type and minimum or maximum length or value.
• Sort order: Allows you to define a logical sequence of how the fields are arranged within forms and tables.
• Field size: Allows you to specify the width of the field from 1-12, where 12 covers the full width of the page.
• Tooltip: A hover over tooltip that helps guide the user on what is required for this piece of information. This supports markdown formatting so you can embed images, link to other materials (for example internal documentation) or simply use rich formatting to drive the ideal experience for your users. To learn more about markdown formatting, expand the accordion below.
• Component Type: Defines what form of the component to use in the field:
  • For string field, “textbox” only allows plaintext input, whereas “textarea” permits the use of markdown.
  • Number, Date and Boolean only have a single option available.
• Is required: Allows you to define how important the population of each field is:
  • Required: New records can’t be saved without this being populated.
  • Preferred – red: If a record is missing this, a red flag will be triggered for conformance monitoring.
  • Preferred – amber: If a record is missing this, an amber flag will be triggered for conformance monitoring.
  • Optional: This field is available to populate but triggers no warnings if left empty.
• Is advanced column: Determines if the table will display this field by default when the user clicks the Show advanced columns button.
• Is displayed in primary tables: If true, the field will be shown in the Object Type list table.
• Is displayed in secondary tables: If true, the field will be shown in the secondary tables.

| Table  | Column | Header |
| ------ | ------ | ------ |
| First  | row    | here   |
| Second | row    | here   |

Association Types

Moving beyond specifying the fields users need to populate, there’s also the option to specify the associations from this Object to other Object Types too. This could take the form of:

• References: The allow you to define drop-down options within the form itself (i.e. reference lists) such as for ensuring risk levels assigned to a data asset are from a defined list, or business units that a process belongs to are consistently represented. Associations of this type act similarly to a new field and have the same options from a configuration perspective, so that the surfacing of these picklists can be configured to drive a sensible page layout.
• Is child of: this mapping allows you to group metadata appropriately (for example processes have a parent of ‘business function’ or ‘business unit’ and ‘data terms’ are grouped by ‘domain/entity’). This Association Type drive the navigation between Objects as users traverse the hierarchy of the Catalog.
  • When this is selected you have the option to choose if you want this context to be displayed in the tables themselves (primary/secondary) and whether it should appear by default or as an advanced column.
• Is Assigned With: Many-to-many relationship mappings so that processes can be mapped to the data fueling it, or the critical data elements that are crucial to it’s successful execution. Associations of this type result in a table being displayed alongside the Object so as multiple entries can be shown.

Interest Types

Lastly, Interest Types can also be specified (if required) to allow roles to be explicitly assigned to users within the tool. This can be mapped at a user or a group level and can be aligned to appropriate terminology. For example, against a Policy you might want to ensure an ‘executive sponsor’ is assigned, against a Data Asset you might want to map a ‘steward’ an ‘owner’ and a ‘custodian’, or against a Business Process you might want to map who is ‘responsible’ ‘accountable’ and ‘consulted’.

As with reference associations and the population of fields, conformance monitoring logic can be configured at the interest assignment level allowing you to choose how crucial the mapping of each Interest Type is within the ‘Is required’ setting:

• Required: New records can’t be saved without this Interest Type being assigned.
• Preferred – red: If unassigned, this triggers a red flag for conformance monitoring.
• Preferred – amber: If unassigned ,this triggers an amber flag for conformance monitoring.
• Optional: The assignment of this Interest is available if needed but triggers no warnings if left unassigned.

Within this area, Catalog admins can also optionally allow users to subscribe to updates for each Object of this type. For example, a user can subscribe to updates relating to a specific Policy so that they get notified against any updates relating to this item.