Collibra Governance Reviews

I am currently working with Collibra Governance in data management strategies, specifically focusing on data governance. We are in the process of onboarding all application metadata onto the Collibra data governance platform, facilitating data stewardship, and onboarding users. We have currently onboarded 20-30 applications and associated them with business and technical metadata. We also have plans to onboard over 100 additional applications.

One of the most valuable features of Collibra Governance is its scanning feature, which allows us to onboard multiple applications and their underlying databases. We are also using features like business glossary and data sensitivity, along with the stewardship feature. Additionally, we are planning to integrate Collibra with SecurPie for access control management.

We are a customer of Collibra. Collibra Governance is applied in our data management workflows by creating all the business functions separately, maintaining the data sources of those KPIs and everything separately on those businesses.

Collibra Governance provides ease of use. The portal is self-explanatory with lots of documentation on its usage, making implementation and understanding simple for our team.

It is mainly for documentation purposes, to document metadata in a data catalog, and also to improve understanding, access, and exploration of data.

I've been an external consultant, advising clients on IT solutions and helping them implement these solutions, including Collibra Governance. It's used strategically to find the correct tools for the clients and operationally to implement them.

Previously, I was in high-tech, now I'm in healthcare. In both instances, we used this solution to increase data literacy and business literacy. In short, we were building out business glossaries, coming to an agreement on term definitions, understanding what reports mean, what the metrics and calculations mean — essentially getting it all documented in an enterprise-facing view. That was the bulk of the focus in my prior company — along with some reference data. At my current company, we are focused heavily on bringing in data dictionaries, including schema tables and columns, and understanding what data is in which database. We also look at what data is flowing from database to database and how it's used in Tableau reports or in a business or archive.

Currently, we're on-premises, but we're planning on moving to the cloud later this year.

Over the last 12 months, we've had 643 unique new users. Most of our users tend to be what I would call "data geeks". They are the ones that understand the value of and/or the aspect of leadership to catalog their metadata for their data dictionaries, etc. The business users have not had as much adoption at my current company because that's not the particular strategy at this time. At my prior company, that was the singular strategy — to increase business literacy.

In regard to my previous company, for eight years, our primary customers were business users, not technical users. They just wanted to come in and say, "What does it mean? Who do I talk to if I have questions? Where do I go for more information? How does this relate to that, and how do those things affect me in my business world?" That was a fantastic use case at my prior company. In my current company, we're utilizing the tool specifically to support our data management strategy. Our technology risk office is very much supporting us in the effort to do the cataloging of all of the metadata for all of the systems that we're utilizing, cross-functionally.

Maintenance must be defined. As with any software product that exists, there are regular maintenance upgrades that occur that the company pushes out. If you're on-prem, you can choose to do it sooner versus later. In the Cloud, they push it to you unless you state that you wish to wait. From a maintenance perspective, I have talked to other customers who are in a cloud environment. They say that the maintenance has basically dropped to nil. For on-prem customers, it does require a little more maintenance because obviously, you've got to make sure that the servers are up and running, etc. In my prior role at my previous company, I was responsible for the business IT side of it, which meant I kind of managed the platform. I just didn't manage the server.

I took care of the customers, etc. I'm not even a technical person at all, but still, it was not difficult for me. From a maintenance perspective, I don't feel that it is difficult.

If you have custom integrations that have been created, then it will require a little bit more maintenance because those integrations need to be monitored. Some customers require a lot of integration, and some customers don't. It really depends upon the use case. Custom integration is really where it gets more challenging. Depending on whether it's a one-way integration or a two-way data feed, it can get pretty complex. Two-way data feeds are always custom. But that's something that will be on the customer anyway, not Collibra.

We've only just relaunched this solution within the last 15 months. Currently, we only have about 240,000 assets in the tool, but we have a roadmap and plan to onboard a number of our customers. We'll probably double or triple our users over the next 12 months. 

This solution has brought our very diverse cross-functional business teams to one enterprise-facing view, where they can see business glossaries that have been compiled by other teams. From here, they can leverage and understand what reports have been created. If the report exists already, why recreate it? 

Our data management strategy is to start cataloging our data dictionaries and our business glossaries to ensure that we have a common platform across the company. This is helpful when a database is being retired or being converted over to another one. A lot of work goes into documenting what that data attribute means, or what that field name means in regard to a particular report, or in a particular database.

My domain is master data management. In master data management, basic data quality, lineages, rule profilings, and similar processes come under Collibra profiling. I use it for these purposes.

I find the rule modification and the replication of the rules in Collibra happens very quickly. This is one of the aspects I appreciate the most. Additionally, the data lineage and catalog features have improved significantly over the years. While they were not perfect three years ago, they are much more mature now and continue to grow each year.

Our use cases include connecting a lot of legacy data systems to our logical components. For example, if somebody has a question that they post to us and say, "Tell me everywhere in our organization where we have a policy stored?" the primary use case is to logically define what a policy is, and then we use Collibra to tie that logical construct to a technical implementation. We may have six or eight, however many, different admin systems. We bring in the schemas of the way that those systems look, and then how a policy exists in this database and this table and this column, for example, in that legacy system. 

The second use case that we implement is the ability to track the provenance or the lineage as to how something changes over time. For example, if we bring data in from a legacy system and we use some tool set (e.g. Azure Data Factory) to extract the data into a Hadoop data lake, and then perform some transformations on it, we want to be able to track it; "It came from the source system here, and this field got changed to this name, and we applied this transformation on this field and it eventually shows up on this report here."

We use it to track where a policy exists and also how it got there: it exists on this report and here's how it got on that report, here are all the steps that it took getting through to that particular report from the actual source system itself. Because quite often what we're finding is that our business users will get a report and they'll say, "I think your report's wrong. How did you get that value on that report?" That provenance or lineage is what helps answer those questions.

We have data stewards who are the resources that if somebody proposes a new logical asset based on what they think the customer means, these data stewards are the ones that would get together and look at what's being proposed and make sure it works across all of our business units for a generic implementation, or create business unit specific terms if required. They're the ones that say a particular system or term or logical construct is ready for consumption by end users.

Another group we have is the end users. We try to have people use Collibra by asking, "Don't tell me what system you want to get access to, tell me what you're looking for in business terms/constructs." In our example, it would be the question, "Tell me about all the policies in our system." They would go to Collibra and "shop" for that data and pick a policy and put it into the shopping cart basket that Collibra provides as part of their interface. Then they would submit that request for approval/access to the underlying data.

We also have data stewards who approve the use of new/updated business terminology and end users who are looking for their data to make business decisions. We also have some power users who are the resources who are setting the direction for the application of where we want to go with it, (e.g. new workflows or new functionality within Collibra).

For us, the Collibra application is an on-premise installation (although we use IaaS VMs to host it on cloud); it is not their SaaS implementation.

One of the biggest questions that we had was we didn't know what to with the our tons of legacy systems. The company I work for is a fairly old company, it's over 120 years old within the insurance industry. There are lots of systems that have been around for upwards of say 40 or 50 years, so we're trying to consolidate and bring those down to target, to go from say 15 systems down to three. But not knowing what's in those other systems makes it difficult to do that rationalization. It's enabled us to first understand what we have and then to figure out how we get down to the target state architecture with a reduced number of target systems.

Collibra is for the classification of data. Collibra is being sourced to all the intakes for the company, which might be legacy systems or new systems or might be lineage as well. Collibra takes up and does its own governance over there, and the data is fed into Ataccama. Ataccama and Collibra seem to be cascaded, but Collibra is the first player. But that doesn't mean it saves a lot for Ataccama.

The solution's most valuable features are its scalability and how it can be integrated to any other intakes.

We are focused primarily on the Data Governance Catalog (DGC) for our data dictionary use. We are not using it for information governance in terms of regulatory compliance, etc. We are focused on business glossary, data catalog, data dictionary, and some workflow processes to help with metadata management and other things.

We are fully updated, and we are using its latest version.

One of the workflows that we're just finishing and rolling out is a certification process. Collibra DGC has an attribute in there called "certified," and it is basically a yes/no choice. We wanted a lot more information about the certification of data sets, so I wrote this workflow, which is probably 30 or 40 steps long. We have a series of criteria that we have to meet in order for a data set to be considered certified. I was able to create attributes for all those and create a workflow that goes hand in hand with data set development so that when somebody competes their work, he or she can pop into Collibra and say, "I have finished this." It logs it and it becomes part of a trust score. It is really nice, and it is making our certification process more robust and the documentation easier to collect and maintain.