Multi-Level Asset Certification
Summary: Tom Friesen, Tom Friesen, discusses the current limitations of asset certification levels in Collibra, noting that assets are either certified or not, which lacks nuance. He suggests the need for multi-level certifications such as Uncertified, Bronze, Silver, and Gold, or descriptive ones like Cataloged, Documented, etc., based on asset type. Various methods for implementing this, including using attributes, status, subtypes, or scopes, each have their compromises, particularly regarding visibility and validation. Tom seeks input on other possible solutions and whether there are any ongoing developments in Collibra to support multi-level certifications.
Hey all,
Currently, Collibra provides a mechanism to convey a Certification Level associated with an asset, but it's rather limited: an asset is either certified or not.
Certification is a good thing: it conveys to the viewer of an asset that there is a certain level of trustability associated with it. But I've found that through the lifecycle of an asset, it's a little more common to want to have levels of certification. One might have, for example, Uncertified -> Bronze -> Silver -> Gold levels of certification. Or maybe something more descriptive based on thew Asset Type, such as Cataloged -> Documented -> Traceable -> Monitored Quality.
I've considered a number of ways in which this could be implemented, but each make compromises. The biggest compromise is usually around the visibility and validation of characteristics that are necessary only at higher levels of certification. At lower levels, they are unnecessary — or even noisy. But here are some ideas so far:
Certification Level as an Attribute
This is a simple solution, and doesn't get in the way of Report ingestion.
But complicates the UX and Validation Rule writing, and doesn't have the type/status level of visibility.Certification Level as a Status
Similar to the Attribute solution. But this can — depending on your asset lifecycle — effectively call for an entirely new set of statuses during the revision and up-cert'ing of assets.Certification Level using Asset Subtypes
One might have a Power BI Report Asset Type, with subtypes of Power BI Report - Bronze, Power BI Report - Silver, Power BI Report - Gold. This works very well for Validation and automated guidance for asset owners and SMEs, and is quite visible to viewers of these reports. There is likely a challenge were assets are integrated, as the current Lineage ingestion mechanism always reverts the Asset Type to the Power BI Report Asset Type on ingestion. This is also more difficult to scale if numerous Asset Types are to have multiple levels.Certification Level through Scopes
One could implement this also through the use of Scopes, but this is dependent on the assets living in very specific domains. Ingestion might again be a problem, and this is a non starter for most scenarios, where governance responsibilities are established at the Domain and Community levels.
What do you think about the above ideas? Are there other ways to approach this?
Are there Collibra product developments in this area, or in areas of lifecycles or traits that might lend themselves to a better solution?
What do you do to convey the maturity and trust of assets within your organization's platform?
I'd love to hear from people on this one!
Stefan Busch
·10 months agoHi,
I agree with you that the current implementation of the asset certification is lacking (maybe one should create an entry on the ideation plattform).
Regarding your ideas:
I believe number 3 and 4 are not that suitable. Having multiple asset types to represent the level of certification could be a hassle because you need to keep them in sync (regarding the attribute / relation types of each asset type, etc.) and the scope of an asset is not really shown to the user I think.
I think your first idea to use an attribute may be a good start if you just want to test if this could benefit your users.
The second idea of using the status would be my currently prefered method if I had to implement it. This does indeed require new statuses (and modifying any processes that use them) but they are also just as visible as the asset types.
A fifth idea would be to use tags. This is kinda similar to the attribute type idea with the difference, that you don't need a new attribute type and that the tags are showed on the "at a glance" section on the right side of the asset page (which is a bit better regarding the UI/UX in my opinion).
But we currently do not have any specific implementation of this. The way we handle the documentation of assets right now is, that everything that is meant for the whole organization (like dataproducts) has to go through a specific process to create these assets. This guarantees that the user has to document the asset to some degree that we want.
For assets that are not shared (that live in the community of that department) we do not make any requirements regarding the documentation right now.