Data and Use Case Governance Workflows

Has anyone built a data source and use case governance workflow in Foundry? I’m thinking of something where someone can create a new Use Case object and then link it to the required data source objects that have properties like maturity level (manual, automated, automated with solid ownership and tests, etc) so we have a record of the different use cases and people can figure out if the current data maturity will satisfy their use cases.

Or am I thinking about this wrong? Should we just leverage the built-in tooling in Foundry to do this? eg. Data Catalog, Project Owners, Health Checks, etc.

Hi,

Yup I’ve built this out for a few customers who refer to it as their Metadata Ontology.

Some relevant but optional object types can also include a Foundry Resource object type that hits the Foundry APIs for easy linking of not just the Data Connection sources, but a singular Use Case project that houses things like the Code Repositories, Pipeline Builder files, key datasets, Workshop applications, etc. I’ve implemented this with other object types (and relevant links) like Multipass Users and Groups so in a single Workshop application, PMs and use case owners + their developers can track who has what level(s) of access to which resources (i.e., who can view this Workshop but not apply edits via actions, who can discover it, etc.).

At Ontologize, our example product also includes a Use Case Phase object type that links to the Use Case object; it has additional timestamp properties that track target vs expected vs actual start and end times of each phase of development. This can then be used in Workshop’s Gantt Chart widget.

2 Likes

We have our own Meta Ontology with Data Ingestion Requests, Data Enhancement Requests, various objects wrapping compass resources (Sources, Syncs, Multipass Groups, TPAs…), Data Treasury Items, Use Cases, Use case Extensions, … the list goes on for some time.

I (and many others) have been bugging PD to at least provide the Compass resources as ootb ontology (so we can stop hitting the APIs) and according to my sources it’s been tried a few times :sweat_smile: the controversial point seems to be the permission setup…

In general the setup works quite well and I would recommend it over using the built-in primitives as they mostly are not flexible enough to accommodate the requirements of every business.

2 Likes

Thanks @nicornk - it sounds like a Metadata Ontology is the way to go. Do you have any more details on the data model that you can share?